@DLosc I would say it's a spectrum, but most golflangs (CJam, Husk, Pyth, etc.) lie closer to (2).

05AB1E is slightly less so because it allows interchange between integers and strings.

Jelly is kind of like this as well because autovectorization means that builtins can't overload between scalars and lists.

@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.

Ah, okay. Interesting.

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.