@EsolangingFruit I don't know a lot about Jelly, but I was definitely thinking of it as an example of (1). E.g. the + operator represents mathematical addition, and that's still true if the operands are lists rather than numbers.
Or (from a randomly chosen Jelly answer) V is "evaluate as Jelly code"; but if it's given a list of integers, it casts the integers to strings, joins them, and evaluates that (!), instead of overloading V to mean something different with lists.
@DLosc On the other hand, there are several functions overloaded between different scalar data types. For example, Ċ is "ceiling" for real numbers and "imaginary part" for complex numbers; Ḟ is "floor" for real numbers and "real part" for complex numbers; + is "add" for numbers and "pair" for characters, etc.
Since Jelly seems pretty dominant these days, I was wondering if that means approach (1) is better than approach (2), or if the tacit programming paradigm is what does it.
For all of Jelly's success, there hasn't been a lot of experimentation in that area. Most attempted new golfing languages are stack-based, probably because they're easier to implement.
The only languages similar to Jelly I can think of are its inspirations, J and APL, as well as M, which is essentially Jelly with different builtins.
Yeah. I still haven't quite wrapped my head around that family's execution model. Right now I'm playing around with some ideas for a language that's somewhere in between stack-based and tape-based. We'll see whether it ends up any shorter than a standard stack-based language.
It's a good idea not to design a golfing language around having lots of builtins. People look at Mathematica or golfing language instruction lists and think "I want to make a language like that!"
In reality, golfing languages accrete features over time as they are needed. It's far more important to have an innovative execution model.
"Features" is not a design goal.
So in my opinion golfing languages that overload as much as possible to allow for more builtins are misguided.
