Hello all, i'm trying to figure out a language syntax and I keep going in circles, maybe some opinions from other devs may help.

For a given programming language what is the most efficient & cleanest way of describing a variable, type, etc?

Here is a list of ones I have considered. (psudocode)

C style (structs and return type prefix), pros: simple, really succinct, cons: annoying lexing because return type is ambiguous.

struct Vec3 {
  f32 v[3];
}
struct Player {
  char *username;
  Vec3 pos;
  Color appearance;
}
Player[] login(Player p, char *password) {
...
}
Player me("me", Vec3(0.0,0.0,0.0), Color(255, 0, 0));
login(me, password);

Rust style (function prefix, arrow return type), pros: separation of data and implementation makes composition easier. Cons: not very intuitive for learners.

struct Player {
  username: str,
  pos: Vec3,
  appearance: Color,
}
impl Player {
  fn login(self, pass: str) -> Vec<Player> {
  ...
  }
}
let me: Player = Player {username="me", ...
me.login(password);

Typescript style (similar to rust but without arrows, also OOP). pros: simple, easy to understand. cons: OOP can cause problems

class Player {
  username: string;
  pos: Vec3;
  appearance: Color;
  constructor(username: string, pos: Vec3, appearance: Color) {
    this.username = username;
    ...
  }
  login(password: string):Player[] {
  ...
  }
}
let me: Player = Player(...
me.login(password);

Fortran style (types below definition). Pros: clear whats going on? (maybe too used to fortran weirdness). Cons: extremely verbose.

type player
  string :: username
  real(kind=32), dimension(3) :: pos
  integer(kind=8), dimension(3) :: appearance
contains
  procedure :: login
end type player

player function init_player(username, position, appearance) result(this)
      string :: username
      real(kind=32), dimension(3) :: position
      integer(kind=8), dimension(3) :: appearance

      this%username = username
      this%position = position
      this%appearance = appearance
end function

function login(this, password) result(players)
  class(player) :: this
  string :: password
  player, dimension(:), allocateable :: players
  ...
end function
...
player :: me
me = Player("me" ...
me%login(password)

Go style, types after like rust/typescript but no :, interfaces instead of OOP, prefix types on the left of functions. Slices also backwards. Pros: simple, cons: syntax is backwards and weird, implementing a tupe would be annoying.

type Player {
  username string
  position Vec3
  appearance Color
}
func (p Player) login(password string) []Player {
...
}
me := Player("me" ...
me.login(...

Let me know what you think, thanks all!

  • zongor [comrade/them, he/him]
    hexagon
    ·
    edit-2
    6 days ago

    Right now I’m only focused on look and taste. For reference the closest to what the end product is it’s going to be a typed lua, really simple and easy to understand. I looked at ML, Haskell but they seemed a bit too esoteric for a new dev. Pascal I totally forgot about, should look at that. I also like rusts syntax but I’m not sure if the way the implementation syntax is obvious.

    Edit: looked at pascal and this looks similar to an early draft of mine lol. I think I moved away from the style of syntax (I used ‘as’ instead of ‘of’) was that it made the declaration really long and the type being at the end of it means you would need to wait to allocate memory until the whole line is parsed in.

    • xj9 [they/them, she/her]
      ·
      edit-2
      5 days ago

      The research I've read on programing HCI seems to indicate that programming languages in general are not intuitive for learners (with the fascinating exception of APL, which borrows from maths syntax. Apparently control flow is not intuitive to non programmers at all lol). ML like syntax is common and likely to be familiar to programmers, but IMO what is "best" is really more about familiarity so just follow your bliss.

      P.S. I'll link to sources when I'm not on mobile

      Video summary

      References (also linked in the video description): Notation as a Tool of Thought; Pane, 2001; Miller, 1981.

      • Llituro [he/him, they/them]M
        ·
        6 days ago

        with the fascinating exception of APL

        i'm friends with a math phd who is a huge APL truther, i'm not sure i can share this information, he might become insufferable. that's really neat though.

      • Faresh@lemmy.ml
        ·
        6 days ago

        Apparently control flow is not intuitive to non programmers at all lol

        If it is the control flow that is not intuitive, what about functional programming languages? Code written in those languages, generally has a more declarative style to it. What do beginners think of those languages? What sets APL apart from functional programming languages? Is it the fact, that beyond not relying heavily on control flow, that it also doesn't stray away too far from math into "computer-specific concepts territory"?

        • xj9 [they/them, she/her]
          ·
          5 days ago

          I updated my comment with links to some research and a video where a guy talks over the concepts in some detail!

    • Zvyozdochka [she/her, pup/pup's]
      ·
      edit-2
      6 days ago

      For reference the closest to what the end product is it’s going to be a typed lua

      Have you looked at Roblox's Luau? It might be a good place to get some ideas from.

      • zongor [comrade/them, he/him]
        hexagon
        ·
        edit-2
        6 days ago

        Luau seems to be a typescript/rust mixture with a pinch of Fortran. It’s serviceable but it’s limited in its primitive types. That’s a different issue I’m still thinking of but that’s not for this one.