2 ms·

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 t

by 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.
- kreco 6y ago
  Yes, I can see the design of D was made carefully. D is actually a great language. I just "don't understand" why it's not massively used instead of more recent versions of C++, I consider newer version of C++ as a totally different language with more drawbacks than advantages. Half of new features are present to fix previous half baked features. This is quite embarrassing. Sorry for my selection of words (and for the unrelated opinion, I had to rant), I'm not good at spending time to rephrase when the end content is the same. I remember one time I spent the whole day browsing the website of D, everything actually make sense. There are still features that I wouldn't use, but this is what I expect from a programming language design. I was impressed by a lot of decisions. I seemed to remember that I was a bit sad to not find proper performance benchmarks against other languages. I was intrigued because the documentation was so complete, it was just lacking this (maybe I just couldn't find them). It was a long time ago so it has probably been fixed. I will give it a try at some point.
  - WalterBright 6y ago
    The performance of D vs C and C++ should be identical for code written the same way, as they share the same optimizer and code generators. Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc. We encourage people to run their own benchmarks on their own code and let the results speak for themselves. One issue with moving to D is it takes a while for people to learn "the D way". For example, if they come from C they write C style code in D. From C++, they write C++ style in D. From Python they write Python style in D. Inevitably they'll run into some difference where D doesn't have an analogous feature, and would get a bit frustrated (even though in D the task would be accomplished a different way). It takes a bit of perseverance and faith to get through that until one discovers "the D way" and then they're hooked. One of the reasons for DasBetterC was to reduce this issue as much as possible, though the people who like metaprogramming with the C preprocessor will have more work to do in getting adapted to D's powerful metaprogramming features, which of course work nothing like text macros.
AndyKelley 6y ago
> The worst, no default values for struct. This is incorrect. There are other factual errors here as well.

by kreco 6y ago

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.

kreco 6y ago
Yes, I can see the design of D was made carefully. D is actually a great language. I just "don't understand" why it's not massively used instead of more recent versions of C++, I consider newer version of C++ as a totally different language with more drawbacks than advantages. Half of new features are present to fix previous half baked features. This is quite embarrassing. Sorry for my selection of words (and for the unrelated opinion, I had to rant), I'm not good at spending time to rephrase when the end content is the same. I remember one time I spent the whole day browsing the website of D, everything actually make sense. There are still features that I wouldn't use, but this is what I expect from a programming language design. I was impressed by a lot of decisions. I seemed to remember that I was a bit sad to not find proper performance benchmarks against other languages. I was intrigued because the documentation was so complete, it was just lacking this (maybe I just couldn't find them). It was a long time ago so it has probably been fixed. I will give it a try at some point.
- WalterBright 6y ago
  The performance of D vs C and C++ should be identical for code written the same way, as they share the same optimizer and code generators. Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc. We encourage people to run their own benchmarks on their own code and let the results speak for themselves. One issue with moving to D is it takes a while for people to learn "the D way". For example, if they come from C they write C style code in D. From C++, they write C++ style in D. From Python they write Python style in D. Inevitably they'll run into some difference where D doesn't have an analogous feature, and would get a bit frustrated (even though in D the task would be accomplished a different way). It takes a bit of perseverance and faith to get through that until one discovers "the D way" and then they're hooked. One of the reasons for DasBetterC was to reduce this issue as much as possible, though the people who like metaprogramming with the C preprocessor will have more work to do in getting adapted to D's powerful metaprogramming features, which of course work nothing like text macros.

AndyKelley 6y ago

> The worst, no default values for struct. This is incorrect. There are other factual errors here as well.