1. 7
  1.  

  2. 3

    I’m starting to feel new-language burnout, I’m afraid. Nim has similar benefits, compiling to JS or native code (via C/C++). There are frameworks for using Nim in the browser. Why this and not Nim?

    1. 2

      Ok but why this and not - say - the various ML-alike-for-web languages?

      1. 2

        Which one do you have in mind? If you specify one, I will compare.

        1. 2
      2. 0

        Here are my notes:

        • Not requiring semicola is good.

        • My least favorite parts are the mixed case types and generics with <>… in both cases I would have hoped that people would have stopped repeating these mistakes.

        • Not sure what to think about ident Type syntax.

        • The collection literals and the general amount of operator overloading is something I would personally avoid.

        • Having no “static” is good.

        • Replacing modifiers with annotations is good, I have done the same.

        1. 1

          I think these notes are weak because you’re solely talking about syntax, which I believe is one of if not the least important choices in making a programming language. Memory management, runtime overhead, package management, et al are far more important than using angle brackets for generics.

          1. 4

            Ah the pseudo-intellectual “syntax doesn’t matter” trope.

            I’d love to live in a world were syntax was good enough to not worry about it. Sadly we don’t live in that world.

            And to be honest, looking at the syntax is a good way to discard languages early on. If the syntax is bad, the semantics won’t be great either.

          2. 1

            My least favorite parts are the mixed case types … I would have hoped that people would have stopped repeating these mistakes

            Are you really bikeshedding about CamelCase vs snake_case? I thought we were over that. 😬 Live and let live.

            As for generics brackets, familiarity can beat out grammatical convenience. Most people are used to angle brackets from C++, Java, Rust, etc.

            1. 4

              Are you really bikeshedding about CamelCase vs snake_case?

              No. I meant that bool, int, double and string are lower-case while StringBuilder, Box, List, etc, start with an uppercase letter. Looks like an oversight in any language created after 2000.

              As for generics brackets, familiarity can beat out grammatical convenience.

              According to that, cars should also be steered as if they were drawn by horses. It’s not about “convenience”, it’s that no one has figured out how to deal with <> without exposing the needless complexity of that choice to users.

              I prefer languages without needless complexity.

              Most people are used to angle brackets from C++, Java, Rust, etc.

              And it has been a costly disaster in all of them. Sure, let’s excuse C++ because it was the least bad option to retrofit generics into an existsing language. But if you are creating a new language with generics, using <> is an inexcusable mistake.

              1. 1

                I believed that until recently, when Vale found a really elegant solution to disambiguate binary operators from generics: require binary operators to have a space on each side, otherwise they’re generics. With that one adjustment (which is already required by a lot of major styles guides), all the ambiguity disappeared. It’s nice, because then Vale can use square brackets for other things.

                I also like Rust’s solution (the ::<>), it may be a bit awkward-looking but it solves all the problems.

                It may have been a costly disaster and inexcusable mistake a while ago, but nowadays because of these mitigations we can use angle brackets with no problems. That said, I’m not sure if Skew is employing these mitigations.

                1. 1

                  I think introducing a (likely the only) whitespace-sensitive rule into a language to ad-hoc solve this issue is not a good idea.

                  I also like Rust’s solution (the ::<>), it may be a bit awkward-looking but it solves all the problems.

                  I don’t; I think it’s rather embarrassing for a language to end up with 4 different syntax variations that are only valid in specific contexts.

                  But even if <> did not require such workarounds, I still wouldn’t want to use it, because using <> as brackets is just poorly readable (especially compared to []).

                  If fate didn’t end up forcing C++ down this route, would we “invent” using <> today? I’d say we wouldn’t.

                  Let’s just let generics with <> die. There is no reason to use them.

                  1. 1

                    Your claim about readability is subjective. I find <> to be equally readable to [], and before that, <> was more readable because it was more familiar. Familiarity is important for readability, especially for a new language. Not many languages use [].

                    We use whitespace sensitivity all the time, in every language I’ve seen. It’s everywhere once you start looking. For example, “void myfunc() { … }” needs a space between void and myfunc. In our case in Vale, it was an easy choice because having spaces around binary operators is more readable anyway (IMO).

                    There’s a big reason to use <> over []: the opportunity cost for []. In Vale, once we freed those up, we were able to use [] for tuples.

                    With all that, it’s a slam-dunk case, <> is a better choice for a new language.

                    1. 1

                      < and > are used as a binary operator for the first 15 years of everyone’s lives. Whatever it is is, it’s not “familiar” to overload it with a different meaning.

                      With Go joining Eiffel, Scala, Python and Nim, I think the tide is turning anyway. (Similar to how ident: Type replaced Type ident earlier on.)

                      Being able to use [] for random things is not a plus either. Using () for terms and [] for types is easy and consistent. Other approaches aren’t.

                      In the end, languages using <> have a steep hill to climb for me to consider them worthwhile a second look.

                2. 1

                  You mean because of parsing ambiguity?

                  1. 1

                    Yes, especially how the syntax ambiguities have a deep impact on the user.

                    To be clear, there are syntactic complexities that are worth it and that can be cleanly hidden from the user. This isn’t one of them, as we have experienced for a few decades now.

                    1. 1

                      FWIW I think that might be solvable on the parser’s end, at least for a java-ish syntax.

                      Source: I wrote a parsing library

                      1. 1

                        Java has not-so-nice user-facing syntax to work around issues, like foo.<Bar>baz().

                        In the end you can solve pretty much everything with unlimited lookahead (see C#), the question really is why, when there are much better options available.

                  2. 1

                    Oh, I see. That does seem inconsistent … I just noticed that Nim makes the same mistake. I’m actually happy for scalar primitives like ‘int’ to be lowercase, but if Box and List are capitalized then String should be too.

                    IIRC, angle brackets are troublesome for the lexer because of ambiguity with other tokens. Not aware of ways they’ve caused problems (since C++11) for users of languages, who vastly outnumber compiler writers.