5 ms·

Every "feature" in Odin was added because it has been shown to be good and consistent with the rest of the language. Slice expressions and range expressions be

Every "feature" in Odin was added because it has been shown to be good and consistent with the rest of the language. Slice expressions and range expressions being different was on purpose, as they are very different operations semantically and I wanted to make this clear with the syntax. You can try to unify them but then you lose the abilities to other things which make them distinct which the current syntax offers. It's allow about trade-offs. Odin does allow you have custom iterators, and C-like for loops do have their uses at times. `new` returns pointer. `free` takes a pointer. `make` returns a non-pointer data structure which contains internal pointers. `delete` will `free` the internal pointers for specific data structures. As for the other criticisms, I recommend trying the language itself first to see why they are made. It is not always possible to just do a quick read of a language to understand its decisions.

fasfsadfsa 5y ago
I don't feel you answered the questions fully. Telling someone to learn the language to get the rest of the answers isn't right and would put me off it because it suggests there aren't satisfactory reasons for the design. I'm sure that's not the case but still.
- filipncs 5y ago
  I, on the other hand, am not in any way put off by someone not trying to answer every single part of a comment, when it starts out with "Odin seems like a bunch of features copied from a bunch of different languages without making sure they're (a) good and (b) consistent"!
  - jessermeyer 5y ago
    Not only that, but without even knowing the answer to their (valid) questions, concludes with `it's a patchwork with bad seams.`.
    - fasfsadfsa 5y ago
      I agree it should not have ended that way.
  - fasfsadfsa 5y ago
    There seemed to be valid questions like > Things like ranges being `1..5` in one context but `1:5` in another Is this true? Perhaps illustrate why "Slice expressions and range expressions [are] different was on purpose, as they are very different operations semantically". You should be able to clear that up easily by pointing to the language overview or something. > but still having classic for loops which ranges almost completely obsolete Is this unreasonable? And > but why add the latter syntax to the language anyway, then tell people not to use it? Same. If there are good reasons there should be good (and simple) explanations. Questions like these should be an opportunity to clarify the whys of the language. Ignoring them is discouraging.
    - gingerBill 5y ago
      For slice expressions, the reason for the syntax was done on purpose for the following reasons: * It's the same syntax as Go and Python, making it familiar to others who have used those languages * It allows for partial ranges e.g. `x[:]`, `x[:n]`, `x[i:]` * Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]` * You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language * Ranges in Odin are only allowed in two contexts: `cases` and `for in` loops. As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator. As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence.
      - fasfsadfsa 5y ago
        Now that's pretty good. May I suggest if it's not there already to add it to the language FAQ? > As for syntax, where does it say "don't use it"? I was quoting the questioner in good faith. If I re-quoted something untrue, sorry. As for why people do things like that, yeah, seen that before and I can't explain it.
ralfn 5y ago
>You can try to unify them but then you lose the abilities to other things which make them distinct which the current syntax offers. It's allow about trade-offs. Can you give an example of such an ability and the kind of tradeoffs we are talking about here? >It is not always possible to just do a quick read of a language to understand its decisions. A successful programming language to me seems to be much more about being able to communicate the design clearly. How is it data oriented in a way languages that don't call themselves data oriented are not? Which constructs do you have they are lacking? Concrete example of an algorithm that is now better/easier to implement? I agree that some people are not very good at communication and might in theory or perhaps accidentally still be able to design a language with interesting choices, but the world will never know about it.

fasfsadfsa 5y ago

I don't feel you answered the questions fully. Telling someone to learn the language to get the rest of the answers isn't right and would put me off it because it suggests there aren't satisfactory reasons for the design. I'm sure that's not the case but still.

filipncs 5y ago
I, on the other hand, am not in any way put off by someone not trying to answer every single part of a comment, when it starts out with "Odin seems like a bunch of features copied from a bunch of different languages without making sure they're (a) good and (b) consistent"!
- jessermeyer 5y ago
  Not only that, but without even knowing the answer to their (valid) questions, concludes with `it's a patchwork with bad seams.`.
  - fasfsadfsa 5y ago
    I agree it should not have ended that way.
- fasfsadfsa 5y ago
  There seemed to be valid questions like > Things like ranges being `1..5` in one context but `1:5` in another Is this true? Perhaps illustrate why "Slice expressions and range expressions [are] different was on purpose, as they are very different operations semantically". You should be able to clear that up easily by pointing to the language overview or something. > but still having classic for loops which ranges almost completely obsolete Is this unreasonable? And > but why add the latter syntax to the language anyway, then tell people not to use it? Same. If there are good reasons there should be good (and simple) explanations. Questions like these should be an opportunity to clarify the whys of the language. Ignoring them is discouraging.
  - gingerBill 5y ago
    For slice expressions, the reason for the syntax was done on purpose for the following reasons: * It's the same syntax as Go and Python, making it familiar to others who have used those languages * It allows for partial ranges e.g. `x[:]`, `x[:n]`, `x[i:]` * Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]` * You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language * Ranges in Odin are only allowed in two contexts: `cases` and `for in` loops. As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator. As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence.
    - fasfsadfsa 5y ago
      Now that's pretty good. May I suggest if it's not there already to add it to the language FAQ? > As for syntax, where does it say "don't use it"? I was quoting the questioner in good faith. If I re-quoted something untrue, sorry. As for why people do things like that, yeah, seen that before and I can't explain it.

ralfn 5y ago

>You can try to unify them but then you lose the abilities to other things which make them distinct which the current syntax offers. It's allow about trade-offs. Can you give an example of such an ability and the kind of tradeoffs we are talking about here? >It is not always possible to just do a quick read of a language to understand its decisions. A successful programming language to me seems to be much more about being able to communicate the design clearly. How is it data oriented in a way languages that don't call themselves data oriented are not? Which constructs do you have they are lacking? Concrete example of an algorithm that is now better/easier to implement? I agree that some people are not very good at communication and might in theory or perhaps accidentally still be able to design a language with interesting choices, but the world will never know about it.