4 ms·

First, I said screw with windows users. Second, none of those languages error on carriage returns. Third, whitespace being significant is not the same as error

First, I said screw with windows users. Second, none of those languages error on carriage returns. Third, whitespace being significant is not the same as erroring out when your users don't use your preferred white space. I don't use tabs for anything, but it is all trivial to handle and they bomb out anyway. It's a slap in the face to users and it's "rude" to waste people's time by making them deal with nonsense. It is not "rude" to point out that a piece of software does this. Also none of what you put here is an an actual justification for stuff like this. This is like being in the twilight zone, why would anyone defend this?

zamadatix 7y ago
"With" or not with you don't find it a bit ridiculous to say that a group designed a C compatible language that can cross compile to/from Windows easier than any existing C compatible language to this point yet they specifically chose the whitespace as they did because they want to screw with Windows users - no better reason? Again Unix newline style is the least of the worries for whitespace, Windows and built-ins like Notepad handle it just fine for years now if that's what you code in. Try inserting tabs in place of spaces as you please in Python or Haskell though and yes you are likely to run into problems trying to run a program. It's not called "significant whitespace" in those languages because it's ignored. It's fine to point out you think something is harder to use than it needs to be but the way you've done it says more about you than the language. You won't a whole language because it requires you run the built in formatter to compile? Might as well not use GCC either it forces you to use -- for options instead of / and other tools handle it just fine they just want to screw with Windows users that's it! What's left to talk about except these kind of nitpicks if that's where you draw the line for ignoring whole projects with years of effort put in them at? None of what I put here was claimed as justification I said the Zig docs link to the reasons. Specifically (in case you'd rather I'd bring them up for you) the reasons were around ease of parsing as a large portion of the syntax was. The whole language specification is actualy very specific about making sure each line can be simply tokenized individually and parsed one way regardless of convetion - not actually so picked just to screw with people that like tabs or Windows. Zig fmt is allowed to "eat" any complexity in normalizing code (referencing ICU data, normalizing whitespace and other syntax, and so on) so zig build-exe doesn't have to. This philosophy of keeping as much functionality out of the core compiler and language is a big part of what allows Zig to target many places e.g. Rust doesn't even though Zig is still very fresh. If running "zig-fmt" as part of your custom build process or using one of the editor plugins ziglang maintains that does this for you is "a slap in the face to users" I'm not sure there is any language those users would be happy with as there are other things they are going to like less than it replacing their whitespace on them. It's certainly not harder to do than post scathing reviews about how you couldn't just use tab on the release discussions though.
- BubRoss 7y ago
  > The whole language specification is actualy very specific about making sure each line can be simply tokenized individually and parsed one way This is the rationalization given, but it doesn't make any sense. Carriage returns could just be ignored. It is completely trivial, especially compared to all the other changes. Can you explain how this explanation actually connects to reality?
  - zamadatix 7y ago
    Again the thought was Zig could take a stance on supporting multiple of the 5-ish line endings and let every tool that is written deal with it and dozens of other whitespace decisions or it could be normalized to 1 way to represent it with no variability in whitespace characters as part of the built in language tooling. Allowing 2 ways is not an alternative path to having 1 way. This concept is extended to all sorts of whitespace characters it's not just about newline and tab. You write about the line ending like you get paid per \r\n you push up to Git, there is no reason to care which whitespace character the formatter outputs for you. Zig init-exe is literally going to do this for you when you make a project. Build.zig can literally run zig fmt for you as part of the build process.
    - BubRoss 7y ago
      There is no "taking a stance". There are two line endings being talked about here, with carriage returns and without. Why are you so desperate to change the goal posts? This change log is hundreds of lines long, you think ignoring carriage returns is a big deal? Why would it matter for tools? Have the tools run zigfmt. Why make users build a script to compile a hello world program? Does zig only allow a single space between tokens? Again you are trying anything you can think of to justify a ridiculous choice because you want to defend zig as a whole. Nothing ads up here. > there is no reason to care which whitespace character the formatter outputs for you. I never said anything about that. I have only talked about the compiler erroring out on carriage returns as an intentional design choice.
      - 7y ago

zamadatix 7y ago

"With" or not with you don't find it a bit ridiculous to say that a group designed a C compatible language that can cross compile to/from Windows easier than any existing C compatible language to this point yet they specifically chose the whitespace as they did because they want to screw with Windows users - no better reason? Again Unix newline style is the least of the worries for whitespace, Windows and built-ins like Notepad handle it just fine for years now if that's what you code in. Try inserting tabs in place of spaces as you please in Python or Haskell though and yes you are likely to run into problems trying to run a program. It's not called "significant whitespace" in those languages because it's ignored. It's fine to point out you think something is harder to use than it needs to be but the way you've done it says more about you than the language. You won't a whole language because it requires you run the built in formatter to compile? Might as well not use GCC either it forces you to use -- for options instead of / and other tools handle it just fine they just want to screw with Windows users that's it! What's left to talk about except these kind of nitpicks if that's where you draw the line for ignoring whole projects with years of effort put in them at? None of what I put here was claimed as justification I said the Zig docs link to the reasons. Specifically (in case you'd rather I'd bring them up for you) the reasons were around ease of parsing as a large portion of the syntax was. The whole language specification is actualy very specific about making sure each line can be simply tokenized individually and parsed one way regardless of convetion - not actually so picked just to screw with people that like tabs or Windows. Zig fmt is allowed to "eat" any complexity in normalizing code (referencing ICU data, normalizing whitespace and other syntax, and so on) so zig build-exe doesn't have to. This philosophy of keeping as much functionality out of the core compiler and language is a big part of what allows Zig to target many places e.g. Rust doesn't even though Zig is still very fresh. If running "zig-fmt" as part of your custom build process or using one of the editor plugins ziglang maintains that does this for you is "a slap in the face to users" I'm not sure there is any language those users would be happy with as there are other things they are going to like less than it replacing their whitespace on them. It's certainly not harder to do than post scathing reviews about how you couldn't just use tab on the release discussions though.

BubRoss 7y ago
> The whole language specification is actualy very specific about making sure each line can be simply tokenized individually and parsed one way This is the rationalization given, but it doesn't make any sense. Carriage returns could just be ignored. It is completely trivial, especially compared to all the other changes. Can you explain how this explanation actually connects to reality?
- zamadatix 7y ago
  Again the thought was Zig could take a stance on supporting multiple of the 5-ish line endings and let every tool that is written deal with it and dozens of other whitespace decisions or it could be normalized to 1 way to represent it with no variability in whitespace characters as part of the built in language tooling. Allowing 2 ways is not an alternative path to having 1 way. This concept is extended to all sorts of whitespace characters it's not just about newline and tab. You write about the line ending like you get paid per \r\n you push up to Git, there is no reason to care which whitespace character the formatter outputs for you. Zig init-exe is literally going to do this for you when you make a project. Build.zig can literally run zig fmt for you as part of the build process.
  - BubRoss 7y ago
    There is no "taking a stance". There are two line endings being talked about here, with carriage returns and without. Why are you so desperate to change the goal posts? This change log is hundreds of lines long, you think ignoring carriage returns is a big deal? Why would it matter for tools? Have the tools run zigfmt. Why make users build a script to compile a hello world program? Does zig only allow a single space between tokens? Again you are trying anything you can think of to justify a ridiculous choice because you want to defend zig as a whole. Nothing ads up here. > there is no reason to care which whitespace character the formatter outputs for you. I never said anything about that. I have only talked about the compiler erroring out on carriage returns as an intentional design choice.
    - 7y ago