On: Gleam: a type safe language on the Erlang VM

[dylukes]

It separates "names as public-facing API design decisions" from "names as developer conveniences for expressing intent and clarifying their code".

These are often very at odds. And if you don't want to repeat yourself twice with two identical names... you don't have to.

And unlike Smalltalk, in Swift at least, externally unnamed but internally named is easy (just make the external name _).

[troupo → dylukes]

> It separates "names as public-facing API design decisions" from "names as developer conveniences for expressing intent and clarifying their code"

How often is this an issue?

> And unlike Smalltalk, in Swift at least, externally unnamed but internally named is easy (just make the external name _).

So, visual clutter for very little gain. IMO

[lpil → troupo]

> How often is this an issue?

In our opinion, almost always.

[troupo → lpil]

As wikipedia would say, [citation needed].

Having shipped code in nearly two dozen different programming languages, there were very few times when I wanted my internal parameter name to be different from my external parameter name. The reasons are very simple:

- if your function is simple, you just use the params immediately, like in your `replace` example. It doesn't matter what they are called as long as their names make sense

- if your function is not simple, the parameters are usually immediately transformed into something else (mapped to different data, split to different data etc.), and their original name doesn't matter.

So this leaves a small weird case of "somehow parameter names don't make sense for the caller of the function", and I can't for the life of me come up with such an example (the example with replace in Gleam docs is not convincing, to say the least).

[dylukes → troupo]

Two dozen programming languages shipped in or not, almost no languages support this.

It is something that you start appreciating a lot more once you have used it significantly. It helps a lot with writing more self-documenting interfaces that are legible at a glance.

Another detail I did not mention is that _public names are part of the interface_. This means that two functions that differ only in the public names are distinct overloads.

To give an extremely simple example (taken from Apple's docs):

class Counter {

    var count = 0

    func increment() {
        count += 1
    }
    
    func increment(by amount: Int) {
        count += amount
    }
    ...

}

This starts becoming even more valuable when you have more complex objects, and allows you to move (e.g. on some kind of repository class) mangling of overload names into more readable named argument overloads.