High-friction languages allow you to pump your codebase full of unbounded coupling and complexity, to turn your codebase into a hypercube of connections (subclasses; interfaces; macros; annotations; DSLs; monkey-patches; etc.) IDEs for these languages give you a fancy N-dimensional submarine to efficiently navigate this "wondrous" landscape.

Low-friction programming languages just don't give people all those N dimensions of inter-module connectivity in the first place; and for what dimensions they do provide, they steer people away from using them too often, perhaps with opinionated linting, or by building the standard library out of the simple stuff, such that all code that interacts with the stdlib keeps to the same simple style to avoid style-clash.

This approach will also "reduce the cognitive load someone has to experience contributing to code that they didn't write"; but it reduces that cognitive load even for people reading the code in a text editor. Or for the maintainers throwing snippets of the code around in a PR / patch-submission mailing-list.

For general interest, what programming languages do you classify as low-friction?

gawk

> subclasses; interfaces; macros; annotations; DSLs; monkey-patches; etc.

I think this excludes every programming language known to man, since 1980 or so :-))

It’s not having just one of them is bad; it’s that striving to include as many of them as possible in your language—and not having any convention or constraint discouraging using them all at once—is bad. Look at the code that implements the C++ STL, for example.