4 ms·

Looks pretty promising actually. I love the methodology laid out for the language. I just wish more languages would move away from the C syntax. While we're all

by isaiahg 11y ago

Looks pretty promising actually. I love the methodology laid out for the language. I just wish more languages would move away from the C syntax. While we're all used to that syntax I think Python has been more successful in demonstrating the practicality of whitespace for readability. And considering that readability is a major factor for this language I think it's a shame it doesn't use whitespace more effectively.

nordsieck 11y ago
The big downside to using whitespace in this way is that if you are trying to generate python, especially from another language, it's a nightmare. Explicit delimiters make meta-programming much easier.
- anentropic 11y ago
  yeah but how often do you do that though...
  - PeCaN 11y ago
    If the C preprocessor counts, I do that every day. :-) Otherwise, it's one of those things that you don't realize how useful it is until you can't do it. But not often, and ideally a Sufficiently Expressive Language wouldn't need code generation—but this is targeting C's niche, not Haskell's.
- roryokane 11y ago
  That sounds like a good reason to not use indentation – since Zig is so low-level, it is a good candidate for machine-generation. But I can’t think of a good reason for Zig to separate statements with semicolons instead of unescaped newlines. Zig-generators should be able to generate "\n" as easily as ";". The only reason to keep semicolons I can think of is to look familiar to C programmers, so as not to scare them off. I’m not very familiar with that demographic, but I think most of them would be fine with it, especially if they have used other semicolon-less languages. Semicolons, which are present on about 50% of lines, add visual noise and the cognitive load of remembering to type them.
  - phaylon 11y ago
    There's also the group of people I'm in: I _like_ the explicit semicolons.
  - AndyKelley 11y ago
    Having semicolons introduces simple redundancy to the language. If you leave off semicolons you introduce more ambiguity, which can make error messages less clear since it's less obvious to the compiler exactly what was the mistake the programmer made. Think of it like a sliding scale: on the far extreme of no redundancy, a typo could be a runtime error instead of a compile error. On the far extreme of redundancy, you have to express your code twice in different ways. Having semicolons is a reasonable balance between the extremes.
    - roryokane 11y ago
      I think I understand why semicolons make good error messages easier to implement. However, I don't see anything that makes that same quality of error messages impossible in a language without semicolons. It's just a matter of how much time the language writer is willing to spend on slightly improving the user experience. Semicolons help get a better error message for the following typo, if `foo` can take either 0 or 1 arguments: if (true) { foo(; bar *= 2; baz( "first", "second", ); } The compiler can easily tell you that you forgot a ) on line 2. If semicolons were optional, the program would be this: if (true) { foo( bar *= 2 baz( "first", "second", ) } The simplest error message to implement would complain that you forgot a ) somewhere within lines 2 to 7, and also that the argument to `foo` contains two statements instead of one expression. This error message would be less helpful. However, with the semicolonless language, you could still write the compiler to give the better error message. You could have a heuristic that that this combination of errors suggests a different error, or you could parse indentation for error-checking purposes. It would just require more work on the part of the compiler writer.

by isaiahg 11y ago

nordsieck 11y ago

The big downside to using whitespace in this way is that if you are trying to generate python, especially from another language, it's a nightmare. Explicit delimiters make meta-programming much easier.

anentropic 11y ago
yeah but how often do you do that though...
- PeCaN 11y ago
  If the C preprocessor counts, I do that every day. :-) Otherwise, it's one of those things that you don't realize how useful it is until you can't do it. But not often, and ideally a Sufficiently Expressive Language wouldn't need code generation—but this is targeting C's niche, not Haskell's.
roryokane 11y ago
That sounds like a good reason to not use indentation – since Zig is so low-level, it is a good candidate for machine-generation. But I can’t think of a good reason for Zig to separate statements with semicolons instead of unescaped newlines. Zig-generators should be able to generate "\n" as easily as ";". The only reason to keep semicolons I can think of is to look familiar to C programmers, so as not to scare them off. I’m not very familiar with that demographic, but I think most of them would be fine with it, especially if they have used other semicolon-less languages. Semicolons, which are present on about 50% of lines, add visual noise and the cognitive load of remembering to type them.
- phaylon 11y ago
  There's also the group of people I'm in: I _like_ the explicit semicolons.
- AndyKelley 11y ago
  Having semicolons introduces simple redundancy to the language. If you leave off semicolons you introduce more ambiguity, which can make error messages less clear since it's less obvious to the compiler exactly what was the mistake the programmer made. Think of it like a sliding scale: on the far extreme of no redundancy, a typo could be a runtime error instead of a compile error. On the far extreme of redundancy, you have to express your code twice in different ways. Having semicolons is a reasonable balance between the extremes.
  - roryokane 11y ago
    I think I understand why semicolons make good error messages easier to implement. However, I don't see anything that makes that same quality of error messages impossible in a language without semicolons. It's just a matter of how much time the language writer is willing to spend on slightly improving the user experience. Semicolons help get a better error message for the following typo, if `foo` can take either 0 or 1 arguments: if (true) { foo(; bar *= 2; baz( "first", "second", ); } The compiler can easily tell you that you forgot a ) on line 2. If semicolons were optional, the program would be this: if (true) { foo( bar *= 2 baz( "first", "second", ) } The simplest error message to implement would complain that you forgot a ) somewhere within lines 2 to 7, and also that the argument to `foo` contains two statements instead of one expression. This error message would be less helpful. However, with the semicolonless language, you could still write the compiler to give the better error message. You could have a heuristic that that this combination of errors suggests a different error, or you could parse indentation for error-checking purposes. It would just require more work on the part of the compiler writer.