Gleam: a type safe language on the Erlang VM

Re:Gleam: a type safe language on the Erlang VM by troupo on Wednesday November 08, 2023 @04:08AM (#38188187)

Does it? Instead of a single parameter you now have two names, and a type info to boot

    pub fn replace(
      in string: String,
      each pattern: String,
      with replacement: String,
    ) {
      // The variables `string`, `pattern`, and `replacement` are in scope here
    }

    replace(in: "A,B,C", each: ",", with: " ")

    pub fn replace(
      in: String,
      each: String,
      with: String,
    ) {

    }

    replace(in: "A,B,C", each: ",", with: " ")

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by _glass on Wednesday November 08, 2023 @07:28AM (#38189512)

Wouldn't you have replace("A,B,C", ",", " "), which is quite unreadable.

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by troupo on Wednesday November 08, 2023 @12:17PM (#38193608)

Not if you go the C# way: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by lpil on Wednesday November 08, 2023 @11:03AM (#38192324)

When argument variable names and labels are combined you have two problems:

1. Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API. Gleam is designed to make sure that APIs are always carefully thought about and designed as appropriate.

2. Renaming a variable becomes a breaking change. We don't believe that renaming a variable should ever result in a semver major version bump.

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by troupo on Wednesday November 08, 2023 @12:13PM (#38193533)

> Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API.

1. Not every code is an API. And APIs exist in multiple languages that don't have labels

2. If you wanted named parameters, you could go the C# way: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

3. Since Gleam doesn't enforce labels or check labels in any way, it doesn't "make sure APIs are carefully thought out". Labels will be just as random and accidental as parameter names following the whims of the programmer who decides to use them

> Renaming a variable becomes a breaking change.

So does renaming a label.

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by yaglo on Friday November 10, 2023 @07:23AM (#38218005)

1. Every class/method/function/whatever declaration is an API, doesn't matter if it's internal or which language it's written. 2. Why do you think it's better? It looks like it tries to cater to everyone, and leads to inconsistent API usage and requires teams to agree on linting rules and use tools to enforce consistent coding standards. 3. It's a tool for _you_ to design good APIs that are clear. Languages without named arguments don't give you this tool.

> So does renaming a label.

In languages without this feature, any renaming breaks the API, unlike the ones with distinct internal and external names. This is not the same.

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by zem on Wednesday November 08, 2023 @01:01PM (#38194324)

the idea is that within the function body you would rather refer to the variables as e.g. `for s in string.match(pattern)` than `for s in in.match(each)`

[ Parent | on HN ]

Re:Gleam: a type safe language on the Erlang VM by troupo on Wednesday November 08, 2023 @02:23PM (#38195576)

Then call them that.

`replace(string, pattern)` is just as (if not more) readable as `replace(in, each)`.

I was specifically replying to the claim about readability.

[ Parent | on HN ]