4 ms·

(Edit: this comes across a bit aggressive, not meant so). What benefits does copper bring over other langs? Also loose is a bad move. Loose semantics proved a

(Edit: this comes across a bit aggressive, not meant so). What benefits does copper bring over other langs? Also loose is a bad move. Loose semantics proved a mistake (PL1), loose syntax brings nothing to the party. Semicolons were used in pascal because wirth understood parsing, and they are there to help the parser resync after a syntax error is detected. From experience if you make semicolons optional as in sql, it helps not at all, AND they are (said by microsoft to) become mandatory in future releases of TSQL, AND I and at least some other users of SQL want them mandatory. I also don't understand why a non-typical syntax is used. Not at all saying it's wrong but it seems to differ from other syntactic conventions only to be different rather than better (I may be wrong!). Why "gte(a: 100)"? Syntax matters to a degree, why diverge?

kroltan 6y ago
> Why "gte(a: 100)"? Syntax matters to a degree, why diverge? Not sure what about it are you criticizing? Local variable access using :? No commas between parameters? Operators using function call syntax?
- tom_mellior 6y ago
  Not the parent, but I personally don't like prefix syntax for such common operators. As for the colons combined with the absence of commas, this suggests keyword syntax to me. I.e., as if the gte function took one argument named a. Like this Python call: gte(a=100)
  - deleted 6y ago
    [deleted]
  - nercht12 6y ago
    Actually, it can take multiple. gte(a: b: c: d:) is equivalent to (in C) a >= b && a >= c && a >= d. By making operators like functions, you can group like-operations and simplify code. Admittedly, it's not as readable for someone accustomed to seeing C style. Last note: gte(a=100) would produce an error in Copper because a=100 is an assignment statement that returns "a" (a function), and gte( function ) means nothing. Edit: I see you're referring to Python, but I figured I'd keep the note of comparison.
    - kroltan 6y ago
      That's... surprising, I could easily expect gte(a: b: c: d:) to possibly mean a >= b && b >= c && c >= d I think it's just not as readable precisely because of the ambiguity.
- throwaway_pdp09 6y ago
  Not criticising, asking. > Local variable access using :? / No commas between parameters? / Operators using function call syntax? Well, yes, yes and yes.
  - kroltan 6y ago
    Didn't mean to imply, my bad. Commas and function-call operators is actually pretty common in Lisp-likes, though they usually still use the symbol instead of some shorthand or initialism, and the opening parens comes before the function name: (= (> 4 1) true) I'm not a fan of Copper's local variable syntax though, as the uncle comment by tom_mellior articulated, looks too much like association.
skohan 6y ago
I agree about looseness in general, but I disagree about semicolons. After having gotten used to programming without them, they always feel like a tedious burden which adds no value when I'm working with a language where they're required again.
nercht12 6y ago
An article on the blog explains the parse tree. https://copperlang.wordpress.com/2016/11/18/printsyntax/ https://copperlang.wordpress.com/2016/11/18/printsyntax/ Edit: The design of the parse tree is such that there is no need for things like statement termination, parameter separation, among other things. By its simplicity, the code focuses on what really matters. Complex syntax is mentally taxing and distracts the programmer from focusing his energy on problem solving.
- throwaway_pdp09 6y ago
  > Complex syntax is mentally taxing and distracts the programmer from focusing his energy on problem solving. With respect I don't see it that way (nor know of any studies to back that up qualitatively). While complex syntaxes do exist and they are horrible (I pray you never have to use XSLT) dropping semicolons and commas do not make a syntax noticeably simpler. But they may lay unexpected traps. See how your users find it though.
  - nercht12 6y ago
    The dropping of semicolons and commas isn't what makes it simple, I'll agree. I was referring to the simplicity of the parse tree as a whole. It's easier to figure out what a Copper statement does because there are very few types of statements. Yes, there are a couple of traps [1]. Try reading this example [2] and see how you like it. [1] When passing either an object or data to a function, the parameter is stored as a function. e.g. if f=[p]{}, then f(a) and f(5) have p=a and p=5 respectively. If a=5, then the results are identical. The trap is that if a={ret({ret(5)})}, which is a wrapping function, and you call "a" before passing it to "f", then you get the nested function {ret(5)} instead of the wrapping function {ret({ret(5)})}. Having worked with Copper in practice, it's not too hard to spot the error, but it is one of those things that will catch beginners off guard. [2] https://github.com/chronologicaldot/CupricBridge/blob/master/examples/Tic%20Tac%20Toe/main.cu https://github.com/chronologicaldot/CupricBridge/blob/master...
    - tom_mellior 6y ago

kroltan 6y ago

> Why "gte(a: 100)"? Syntax matters to a degree, why diverge? Not sure what about it are you criticizing? Local variable access using :? No commas between parameters? Operators using function call syntax?

tom_mellior 6y ago
Not the parent, but I personally don't like prefix syntax for such common operators. As for the colons combined with the absence of commas, this suggests keyword syntax to me. I.e., as if the gte function took one argument named a. Like this Python call: gte(a=100)
- deleted 6y ago
  [deleted]
- nercht12 6y ago
  Actually, it can take multiple. gte(a: b: c: d:) is equivalent to (in C) a >= b && a >= c && a >= d. By making operators like functions, you can group like-operations and simplify code. Admittedly, it's not as readable for someone accustomed to seeing C style. Last note: gte(a=100) would produce an error in Copper because a=100 is an assignment statement that returns "a" (a function), and gte( function ) means nothing. Edit: I see you're referring to Python, but I figured I'd keep the note of comparison.
  - kroltan 6y ago
    That's... surprising, I could easily expect gte(a: b: c: d:) to possibly mean a >= b && b >= c && c >= d I think it's just not as readable precisely because of the ambiguity.
throwaway_pdp09 6y ago
Not criticising, asking. > Local variable access using :? / No commas between parameters? / Operators using function call syntax? Well, yes, yes and yes.
- kroltan 6y ago
  Didn't mean to imply, my bad. Commas and function-call operators is actually pretty common in Lisp-likes, though they usually still use the symbol instead of some shorthand or initialism, and the opening parens comes before the function name: (= (> 4 1) true) I'm not a fan of Copper's local variable syntax though, as the uncle comment by tom_mellior articulated, looks too much like association.

skohan 6y ago

I agree about looseness in general, but I disagree about semicolons. After having gotten used to programming without them, they always feel like a tedious burden which adds no value when I'm working with a language where they're required again.

nercht12 6y ago

An article on the blog explains the parse tree. https://copperlang.wordpress.com/2016/11/18/printsyntax/ https://copperlang.wordpress.com/2016/11/18/printsyntax/ Edit: The design of the parse tree is such that there is no need for things like statement termination, parameter separation, among other things. By its simplicity, the code focuses on what really matters. Complex syntax is mentally taxing and distracts the programmer from focusing his energy on problem solving.

throwaway_pdp09 6y ago
> Complex syntax is mentally taxing and distracts the programmer from focusing his energy on problem solving. With respect I don't see it that way (nor know of any studies to back that up qualitatively). While complex syntaxes do exist and they are horrible (I pray you never have to use XSLT) dropping semicolons and commas do not make a syntax noticeably simpler. But they may lay unexpected traps. See how your users find it though.
- nercht12 6y ago
  The dropping of semicolons and commas isn't what makes it simple, I'll agree. I was referring to the simplicity of the parse tree as a whole. It's easier to figure out what a Copper statement does because there are very few types of statements. Yes, there are a couple of traps [1]. Try reading this example [2] and see how you like it. [1] When passing either an object or data to a function, the parameter is stored as a function. e.g. if f=[p]{}, then f(a) and f(5) have p=a and p=5 respectively. If a=5, then the results are identical. The trap is that if a={ret({ret(5)})}, which is a wrapping function, and you call "a" before passing it to "f", then you get the nested function {ret(5)} instead of the wrapping function {ret({ret(5)})}. Having worked with Copper in practice, it's not too hard to spot the error, but it is one of those things that will catch beginners off guard. [2] https://github.com/chronologicaldot/CupricBridge/blob/master/examples/Tic%20Tac%20Toe/main.cu https://github.com/chronologicaldot/CupricBridge/blob/master...
  - tom_mellior 6y ago