4 ms·

Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS

by kreco 6y ago

Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages. Even Zig fails to do better than C, I think it's syntactically a disaster. Here is a few lines from the documentation: const ptr = @intToPtr(?*i32, 0x0); while (it.next()) |item| { /* ... */ } pub fn main() anyerror!void { /* ... */ } exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"}); const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }

snazz 6y ago
Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with any iterator? - anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here. - It has interoperability with (multiple standards of) C. - Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code. So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is simpler and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.
- kreco 6y ago
  Thanks for spending your time explaining this. I think a lof people will understand those lines better. I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax. Since you took your time I will take mine to address what I don't like: - There is no way to write "int" by default. I understand why. But I don't agree. - struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c} - You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not. - You have to type const when importing module: const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct. - the "undefined" keyword when it means "uninitialized" even in the documentation. var my_var: i32 = undefined; - The worst, no default values for struct. - The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror - About iterator I was doing well with: while(get_next(context, &item)) { /* ... */ } It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer. I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).
  - snazz 6y ago
    Thanks for replying! Most of what you wrote makes reasonable sense to me. I guess that a lot of the syntax decisions are subjective. Even if I don’t necessarily agree with all of them, I can appreciate your viewpoints better now.
  - dgellow 6y ago
    Did you reach Zig’s developer regarding the issues you mention? The language isn’t stable yet, good time to try to influence it if you think they are doing some mistake.
    - kreco 6y ago
      I'm not interested in spending time fixing something that is not considered broken by someone else. They are not bugs that have been introduced by mistakes. Don't get me wrong, I like to help people. But I learnt to not help people that do not seek help. You get a plumber fixing your pipes because you need your pipes to be fixed, but if every single plumbers were offering there help it would be annoying. There are already more that three hundreds proposals: https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3Aproposal https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen... A lot of them are about the syntax. Maybe this won't be endless but I'm sure a lot of time are being wasted. The root of the issue I point seems to be bound to the way the devs are working. Not sure if it will be efficient to tell them to "think more carefully". I do believe my time can be more profitable elsewhere (like commenting here, ah ah).
  - WalterBright 6y ago
    > It's like everything has been carefully design to be even less readable than C code. D is designed to be very readable to the C programmer. Some changes, like replacing: (int)(expression) with: cast(int)(expression) is designed to make the code more readable, and greppable. Cast is a fundamentally dangerous operation, so being able to grep-and-check for such is worthwhile. The D compiler actually recognizes the C form and suggests using the D form to fix it. Converting C to DasBetterC is largely just a) eliminating use of the preprocessor and then b) making the syntax changes suggested by the compiler.

by kreco 6y ago

snazz 6y ago

Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with any iterator? - anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here. - It has interoperability with (multiple standards of) C. - Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code. So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is simpler and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.

kreco 6y ago
Thanks for spending your time explaining this. I think a lof people will understand those lines better. I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax. Since you took your time I will take mine to address what I don't like: - There is no way to write "int" by default. I understand why. But I don't agree. - struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c} - You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not. - You have to type const when importing module: const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct. - the "undefined" keyword when it means "uninitialized" even in the documentation. var my_var: i32 = undefined; - The worst, no default values for struct. - The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror - About iterator I was doing well with: while(get_next(context, &item)) { /* ... */ } It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer. I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).
- snazz 6y ago
  Thanks for replying! Most of what you wrote makes reasonable sense to me. I guess that a lot of the syntax decisions are subjective. Even if I don’t necessarily agree with all of them, I can appreciate your viewpoints better now.
- dgellow 6y ago
  Did you reach Zig’s developer regarding the issues you mention? The language isn’t stable yet, good time to try to influence it if you think they are doing some mistake.
  - kreco 6y ago
    I'm not interested in spending time fixing something that is not considered broken by someone else. They are not bugs that have been introduced by mistakes. Don't get me wrong, I like to help people. But I learnt to not help people that do not seek help. You get a plumber fixing your pipes because you need your pipes to be fixed, but if every single plumbers were offering there help it would be annoying. There are already more that three hundreds proposals: https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3Aproposal https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen... A lot of them are about the syntax. Maybe this won't be endless but I'm sure a lot of time are being wasted. The root of the issue I point seems to be bound to the way the devs are working. Not sure if it will be efficient to tell them to "think more carefully". I do believe my time can be more profitable elsewhere (like commenting here, ah ah).
- WalterBright 6y ago
  > It's like everything has been carefully design to be even less readable than C code. D is designed to be very readable to the C programmer. Some changes, like replacing: (int)(expression) with: cast(int)(expression) is designed to make the code more readable, and greppable. Cast is a fundamentally dangerous operation, so being able to grep-and-check for such is worthwhile. The D compiler actually recognizes the C form and suggests using the D form to fix it. Converting C to DasBetterC is largely just a) eliminating use of the preprocessor and then b) making the syntax changes suggested by the compiler.