1. 32
  1.  

  2. 5

    Warning, rant ahead. I’m very excited about Gleam and I think it’s a fantastic idea. I think there are scenarios where having static types could be a boon for people using BEAM. Below is me throwing a fit about syntax so if that’s not your thing just ignore it :).

    I don’t really understand why people use ML style programming, with ML style constructs, with C style syntax. You aren’t making it easier for people who know C, the hard part is learning the paradigms not the syntax. You are making it harder for me to port over code I’ve written in other languages that are actually similar in paradigm. If I actually end up using this I’ll probably just write like a syntax translator from ML style to this. It’s very frustrating to have people consistently reinventing the wheel when the original syntax is fine. Small tweaks are one thing but it’s like if I wrote a C# clone with lisp syntax. The syntax does nothing to serve the actual usage of the language.

    In the end I’ll probably just use Alpaca instead, which doesn’t try to be clever.

    https://github.com/alpaca-lang/alpaca

    1. 7

      Hi, I’m the author of Gleam. I’ve heard this a few times and I’d like to say that just like Alpaca Gleam is explicitly not trying to be an ML language. It is inspired by ML but it is also just as inspired by Rust, Erlang, and a variety of other languages.

      Gleam has several differences compared to ML that I think make it unsuited to ML syntax, the most obvious one being that it does not have automatic currying or partial application.

      Personally I’m less interested in syntax and am happy with both ML and C family style syntaxes (mildly preferring ML), but from looking at ReasonML and mentoring beginner programmers I do think that familiarity goes a long way to making a language approachable. Gleam aims to be friendly and welcoming to people of all experiences and backgrounds, and my working theory is that C style syntax is less of a barrier to entry.

      1. 6

        OK I’ll bite… I think Reason was a good idea because OCaml’s syntax was a significant barrier to me using it (after using 10+ languages and knowing 5 quite well.)

        I wrote a fair bit of OCaml around 5 years ago, and I didn’t have problems with the syntax then, while it was fresh. Now I encounter it in research papers all the time and I can’t read it :-/ To be fair it’s a pretty big language and there are definitely parts of it I didn’t learn.

        I think they make some good critiques here:

        https://reasonml.github.io/docs/en/comparison-to-ocaml#various-improvements

        https://www.reddit.com/r/ocaml/comments/3xvr6n/ocaml_syntax/

        Syntax is obviously personal, but it obviously matters too :)

        1. 2

          They’re doing it because developers have an irrational love of and hatred toward various syntax. The industrial languages with the most adoption kept a C-like syntax for this reason. Probably wise for others to do the same if pulling in programmers using languages like that. If aiming for ML programmers, use ML-like syntax.

          Personally, I’ve argued for new languages to have multiple syntax with the same or similar semantics. Plus, converters for them. Then, people can just use the syntax they prefer. They pull in the source, the converters shift the syntax to their preference, they do their contributions, and submit with others’ converters doing same for them.

          1. 2

            I’ve thought about syntax converters when I’ve come across minor annoyances in syntax, but I can’t imagine that it would be well received in an industrial language. Look at gofmt’s standardization on basic formatting. Additionally, if the secondary syntax was third party created, I can imagine the temptation would be to avoid certain patterns or features in the base language thereby producing a semantically new language.

            Still it might be nice for minor changes. E.g., if you prefer english language keywords (begin, end, not, and, or, etc.) vs punctuation keywords ({, }, &&, ||, !, etc.), then simple manual transformation wouldn’t be too bad.