(This should be on-topic for golfing languages. I've came up with Ckoar, and it would be nice if anyone can implement it/give suggestions on improving golfing experience. It is an array-based language NOT influenced by APL.)
That is a problem in the description, and I don't know how to fix it. Maybe you can specify how they can be replaced (with the cost of increased character variety).
1) There's no way to have a competitive golfing language with 20 commands. You'll either need to use most of the 256 bytes in CP437 (like Jelly, 05A1BE, Actually, ...), or have at least 50 carefully written, heavily overloaded commands and write a "packed" representation (like Stax, which actually has >100).
Even with 100 commands you can fail to be competitive. Packed Pyth is generally no longer competitive, and Pyth took experienced golfer isaacg years to develop.
2) Your basic operations take way too many bytes. Storing subexpressions is one of the basic areas of a good golf language. Stack-based langs dedicate dozens of valuable characters on their codepage to stack-manipulation. Jelly has no variables, but four other ways to store and reuse expressions: $ and friends, μ and friends, the register, and calling links in multi line programs. You can't have your only command to store anything in any space but the current a 2 byte command.
1) If variadic operations are used, then Ckoar should be very competitive in code-golf contests (if every command has a nilad, monad, and dyad form, there will be 768 different commands available. It is a relatively new language.)
@lirtosiast 2) Can you explain why basic operations take too many bytes when the user is preferred to use the CP437 encoding (where all characters are one byte long)?
3) So far this isn't an array-based lang as much as a lang with variables, some of whose names are numbers. Find a way to do something innovative with the theme.
@A__ To store something into a variable or into the array when you're already using the current array slot requires either ↨ or ↑, plus the index number or variable name respectively, which take at least 1 byte.
Btw how do I pronounce Ckoar? Is it shore with a k inserted?
Anyway, what golflangs do you currently know? It's practically required to have familiarity with at least two golflangs with different paradigms before writing one.
I know Keg, based on the stack; and Doug, based on the Arch data structure. I am basing my language on Doug. Doug does even worse than Keg; however, it does better than Python.
lack of any implementation aside, doug is not only deliberately verbose, but based on this "arch" data structure for the novelty of it, not because it's practical
I would recommend to look at my spreadsheet of some popular modern competitive golflangs, select two with different paradigms, read through their docs, and post at least one nontrivial program in each.
Most of them have their own chatrooms where you can ask beginner questions.
Assuming you want to write a competitive golflang I'm not kidding about this. It took me 3 years of golfing in first (imperative) TI-BASIC, then (prefix) Pyth and (tacit) APL and Jelly, while also dabbling in some stack-based langs, before I was ready to start writing my own. And in not knowing Stax or Husk or Canvas or Brachylog, there's still a ton I'm missing.
Yeah, Brachylog’s backtracking and constraint logic are quite useful even if the syntax can be awkward at times, and Husk… I guess its parser is pretty good sometimes, and it’s just overall nice to know
I’ve actually been thinking of making my language transpile to Prolog but I don’t want it to feel too much like Brachylog
Features aside Prolog is just a pleasant language to use, but then if I use it I have no good reason not to use the features
oh yeah and the currying
Husk's currying is great
Other paradigms have various features that accomplish essentially the same thing as partial application, but sometimes there's no substitute for the real thing
@A__ IIRC the first golflang was Golfscript. It sucked (e.g. abs was "abs", not even 1 byte). Once made Golfscript, we found there were significant improvements to be made, and so aditsu wrote CJam. isaacg wrote Pyth, and it became dominant due to its prefix syntax.
After this, the next improvement was Jelly, which Dennis probably came up with because he knew APL/J and CJam.
Since then all competitive languages have had syntax based on solid principles, with tons of builtins that are generally well thought out.
@UnrelatedString Do you know whether Brachylog could be golfier if it were prefix or postfix?
There are some issues with how functionality gets allocated throughout the code page, like how every capital letter is a non-constraint variable, and superscripts and subscripts are separate from each other, but since we're still not even to the point of having written predicates for all of the lowercase non-dotted letters they're minor
And having a coherent aesthetic seems to be a high priority so those aren't really issues that would get addressed
How is the evenness of character use? (I want to eventually run these numbers automatically but I'm having trouble getting non ASCII characters off the SE API)
Unused characters aside, there are probably some capital letters that almost never get written outside string literals because it doesn't really matter how we name our named variables, but that's not quite analogous to the € problem (which I don't think I was here for since I only joined ~~PPCG~~ CG&CC five months ago), but I recall reading the issue on GitHub
The obvious analogue would probably be ᵐ, which of course is map, just like €
It may even be more overused than it was in Jelly since Brachylog just doesn't have vectorization
Also ; is big due to how much Brachylog relies on using lists to pass multiple arguments to predicates
One combination I find myself using a ton is ~c, and I find a subscript on it useful far more often than on non-reversed c.
I also feel like I'm ending up using ~c for things that might be best handled by some sort of metapredicate in the vein of ʰ/ᵗ, but I'm not entirely sure how
Anyhow the biggest way in which Brachylog is not-quite-infix is that instead of having infix operators joining two values into an expression which evaluates to a third value, you have infix operators which take two variables and execute goals on them, and the relationships you declare between the variables are pretty much everything.
And one of the other issues is that although it uses CLP(FD) for integers, and integers in lists, it doesn't really offer the same experience for anything else, so it can be a pain to try to declaratively brute-force strings and lists in general and you end up having to handle them in more of a normal way, except it's not really built to do that
