Made with KolourPaint and screenshots from Kate (with the GitHub theme).

  • Shanmugha@lemmy.world
    1·
    9 days ago

    My attempt of an honest answer to my best knowledge:

    As @TootSweet@lemmy.world mentioned, to make a programming language closer to spoken English language, most likely (hi, Python, I am looking at you too). Which infuriates me immensely: when programming, I do not speak languages, I express data structures and operations on them, stacked one upon another. The last thing I need here is ambiguity, loose structure and information duplication (forgot correct term for the last one) that are typical to natural languages of human communication

  • TootSweet@lemmy.worldEnglish
    0·
    9 days ago

    The Go programming language documentation makes a big deal about how it “reads from left to right.” Like, if you were describing the program in English, the elements of the Go program go in the same order as they would in English.

    I say this as someone who likes Go as a language and writes more of it than any other language: I honestly don’t entirely follow. One example they give is how you specify a type that’s a “slice” (think “list” or “array” or whatever from other languages) of some other type. For instance a “slice of strings” would be written []string. The [] on the left means it’s a slice type. And string on the right specifies what it’s a slice of.

    But does it really make less sense to say “a string slice”?

    In Go, the type always comes after the variable name. A declaration might look like:

    var a string

    Similarly in function declarations:

    func bob(a string, b int, c float64) []string { ... }

    Anyway, I guess all that to say I don’t mind the Go style, but I don’t fully understand the point of it being the way it is, and wouldn’t mind if it was the other way around either.

    Edit: Oh, I might add that my brain will never use the term “a slice of bytes” for []byte. That will forever be “a byte slice” to me. I simply have no choice in the matter. Somehow my brain is much more ok with “a slice of strings”, though.

    • sph@lemmy.world
      0·
      9 days ago

      Go’s syntax is vastly superior once you have more complicated signatures, then the left-to-right truly matters. For example a variable that contains a pointer to a function that takes a function and an int and returns another function (like a decorator).

      In C the order becomes very hard to understand and you really have to read the thing several times to understand the type of fp:

      int (*(*fp)(int (*)(int, int), int))(int, int)

      In Go, you can just read from left to right and you can easily understand what f’s type is:

      f func(func(int,int) int, int) func(int, int) int

      It’s just much more readable.

      See: https://go.dev/blog/declaration-syntax

        • sph@lemmy.world
          0·
          9 days ago

          This obviously just illustrates a point, but callbacks and decorators are not uncommon. And iterators are exactly like that:

          type (
	Seq[V any]     func(yield func(V) bool)
	Seq2[K, V any] func(yield func(K, V) bool)
)

          Which is very readable.

          • phlegmy@sh.itjust.works
            1·
            9 days ago

            Callbacks and decorators are fine, but callbacks/decorators to a function which itself takes a function pointer and returns another function pointer are crazy.

            I’ve thankfully never had to use recursive callbacks or decorators, but it seems like it could very quickly become difficult to keep track of.

  • Oriel Jutty :hhHHHAAAH:@infosec.exchange
    01·
    9 days ago

    Because let x: y is syntactically unambiguous, but you need to know that y names a type in order to correctly parse y x. (Or at least that’s the case in C where a(b) may be a variable declaration or a function call depending on what typedefs are in scope.)

    • HiddenLayer555@lemmy.mlOPEnglish
      1·
      9 days ago

      Can’t say I’ve ever experienced this kind of confusion in Java but that’s probably because they intentionally restricted the syntax so there’s no ambiguity.