All the stack based ones: Forth, Cat, PostScript, etc

Pointfree style in ML-family languages (e.g. Haskell) lets you avoid naming things, though the style was designed more for general conciseness than that specifically.

It’s not fashionable, but perl took from Larry Wall’s linguist background the concept of ‘it’ - i.e. the “thing we are talking about”.

It’s spelt “$_” explicitly in perl, but also many operations use $_ implicitly if no arg is given (e.g. regex/sub, print, etc). Also the looping constructs (for/map/grep) bind $_ to the ‘current element’. So you can:

print for @lines;

and have:

• the for loop loop over each element in the array/list
• bind ‘$_’ as a (mutable!) alias to each list element
• invoke print (which defaults to $_ in the absence of other args)

Or:

while (<STDIN>) {   # Loop over each line on input
  chomp;            # remove trailing \n
  s/foo/bar/;       # regex-and-replace
  say;              # Print to stdout with \n
}

The schwartzian transform (https://en.wikipedia.org/wiki/Schwartzian_transform) uses this, and also the convention/feature that in a block/lambda passed to ‘sort’, the two items under comparison are ‘$a’ and ‘$b’. Which are hence sufficiently magic that you should never use them for any other purpose in perl :-)

Not a language, but a language feature: in Elixir, there’s a capture operator & that will wrap functions in an anonymous function and also can be used to refer to the nth argument of a function. For example:

add_one = fn x -> x + 1 end

is replaced by

add_one = &(&1 + 1)

This helps avoid naming arguments unnecessarily.

Read more

APL-oids are are probably the biggest example (J, Jelly, k/q and so on), followed by stack based and/or concatenative languages (Forth, PostScript and 8th being examples of the former, Cat, Joy and Factor being examples of the latter). After that would likely be functional programming languages (especially with things like Haskell’s point free notation), and then function chains in OO-esqe languages.

Having played around with a stack based language, naming things is hard to get right in the documentation sense, but not naming things is also hard, but in the getting-it-right sense, because then you have to track a lot of implicit stuff, and/or have the compiler show you what the structure at a given point looks like.

I don’t recall the name of it at the moment, but I ran across a programming language that allowed you to just re-use the name of the type if you didn’t have more than one instance of that type in a given scope, which was certainly a novel approach.

The FP language hasn’t been mentioned yet.

John Backus’ Turing award lecture discusses FP in detail.

Most functional languages fit this category. Clojure is a good example of a language that provides great tools to avoid naming transient variables with its various threading macros.

Brainfuck and Piet are esoteric but AFAIK both are designed to work by addressing memory locations, either on a stack or by address, and they have no notion of a named variable or function.

I don’t know whether eschewing naming was a design goal for them, but neither of these languages are especially easy to use directly.

[edit added]

Make has “implicit rules” and “automatic variables” that can prevent the need for naming targets, or even writing any code at all. For example, even without a makefile you can type “make foo” and if “foo.c” exists, it will run the compiler using implicit rules.

Rust encourages shadowing so that multiple transformations of a variable can keep the same name. So the point it is in time refers to the form it takes but they all refer to the same idea, without forcing you to pollute your namespace. I guess this would be error prone in an interpreted language, but the compilation step averts those issues.

Re follow-up question 1, check out “gensym”. It’s mostly a lisp thing.

Seen your update including perl. You ask:

Then the next question is: does it make programming easier (i.e. thinking more about programming and less about naming) or harder (i.e. naming things is documentation).

and the answer to that is that if you’re writing big, maintained perl programs, you typically use explicitly named lexicals. Except where the scope is very short. Not least because the un-named abbreviations have dynamic not lexical scope:

#!/usr/bin/perl
use 5.10.0;

for (qw/foo bar baz/) {
  do_stuff();
  say;      # output $_
}

sub do_stuff() {
  say "wtf $_" if /z/;
}  

$ perl tt.pl
foo
bar
wtf baz
baz

In your opinion, are fewer names a good or bad thing?

As someone who used Clojure’s ->> macro a lot and uses |> in OCaml way more than my coworkers I would say… I prefer to have fewer names and only name “standalone” data, not stuff in the middle of being transformed. In Clojure one can prn in the middle of the chain just fine (same as in JavaScript), in OCaml I usually don’t even need to do that since the type system guarantees that my chain type checks and most of the times I’d mess up it is with the shape of the data not its exact values so the type checker catches most issues I might have when building up pipelines.

I personally also like to shadow names that I expect not to be using in the future to signal to the reader that the previous binding is “dead” and can’t be accidentally used to do the wrong thing.

So yes, I think fewer names is less things to keep in mind and potentially misuse. Also, naming some intermediate byproducts is yields bizarre, nondescriptive names sometimes, which already signals that whatever you are naming is probably something that doesn’t really need a name.

Haskell and bash!!

Swift has a few things, e.g. for anonymous functions you can do the shell-like sum = arr.reduce(0, { $0 + $1 }). The others I can think of (concatenative langs in particular) have already been mentioned. :)

For extreme examples, look up golfing languages, like cjam, golfscript, and pyth.

In Haskell you can just name your variables x, f, m, a, and so on, provided you’re writing at a sufficiently high level of polymorphism, so you don’t usually have to come up with names like handlerFactoryManager.

Agda is even better because you tend to use all kinds of Greek letters, Unicode dingbats, and box-drawing characters.

In your opinion, are fewer names a good or bad thing?

The principle underlying all of the XP practices is “if it hurts, do it more often”. So, what hurts about naming things?

1. Being at the correct level of abstraction. I told you this function calculated the totalSalaryBudgetForDepartment(), so why am I looking at x and xs? Conversely I told you this function calculates totalValueOfNumericPropertyInCollection(), so why am I looking at it in my budget calculator?
2. Finding meaningful and distinct names at the same level of abstraction. When WebObjects switched to Java, almost any application contained the line: Session session = (Session)Session.session();
3. Showing relevant information and hiding irrelevant information. This is a subjective problem: I have had multiple situations where I have wanted to call a method e.g. computeAnswer and somebody else has wanted to call it fetchAnswerComputingIfNecessary when we have both been describing a thing that computes the answer but also memoises.

My opinion is that on balance, more names where they are good names would be a good thing, because they are the ladders that help us up and down between the multiple levels of abstraction in our software. But, as is the case with other forms of documentation, bad names are worse than no names and many developers have chosen to stick with no documentation rather than learning about producing the good.