-
See for yourself: https://ziglang.org/
-
"No preprocessor, no macros."
Why is that an advantage ?
You could write C without any preprocessing but I can't see why you'd do that. It's pretty useful.
-
"No preprocessor, no macros."
Why is that an advantage ?
You could write C without any preprocessing but I can't see why you'd do that. It's pretty useful.
well, in C people abuses so much of cpp and fill so many kind of crap into #define' that it usually ends makeing the ICE confused, the code not passing any QA, and debugging sessions a bloody hell ...
... and I was so tired that "#define" (and the whole cpp-stuff) was the first thing I removed in my-c, at the cost of making "my-c" like a "schoolmarm" who properly educates my colleagues to avoid spending my time cleaning up their code
You can still use #define in my-c but only to define the size of an array, and if you use it then your code is not classified as level{1..4}(1) but rather as level{5} (C89/C99 legacy).Code: [Select]#define macro(a,b,c) .....refused
#define dbg_printf printf
#define foreach ...
etcCode: [Select]#define my_array_size 1024accepted, but the code is forced as level{5} (you cannot use advance my-c features, only C89 legacy ones)
uint8_t my_array[my_array_size];
So, array size by #define is accepted, other uses are banned, alias by different word defined, macros with parameters are recognized but the front end passes them to an "insult-engine" back-end I have implemented into the compiler (built-in, you cannot disable it by any flag) to better promote the cessation and cessation of bad coding attitude.
-
I don't find that to be a good argument, but OK, it's your view.
For your one 'OK' usage, why would you not use const ?
If people 'abuse' cpp, it's because they want to do something otherwise difficult. If you take away that facility they will write worse code, find a worse way to do it, or use a less restrictive language. Of course, people will also abuse it. That's what coding standards are for.
Python is a great example of how this backfires. Forcing a one-size-fits-all layout just makes it impossible to use layout as an aid to understanding. Poor codewriters still write hard-to-read code in python.
One thing I like to use the preprocessor for is to create tables of values that are all derived from some common input. Alternatives would be runtime initialisation (causing slow startup - like many PC programs) or an external code-generator to produce them (so now you've got an infinite variety of preprocessors, according to taste).
You could argue that the comptime features can do that function. And they may be attractive. But, requiring emulation of the target processor, they seem a very expensive way of providing a more capable (and, therefore, abusable) compile-time-processing feature. One could use them to perform exactly the operations described as unpermitted in the preprocessor.
-
Zig existed for a long time, and I don't see it becoming popular. They don't even have for loops and religiously argue that they are not necessary.
And it provides no advantages on top of C. They just removed a bunch of stuff they did not like and shuffled the syntax a bit. -
Seems to me the underlying problem is (someone else's) code not being well enough commented. I don't know if yet another language is the answer.
-
Zig existed for a long time, and I don't see it becoming popular.
Yes, I don't see what the point of the OP was here? It's absolutely not new. Zig was first released in 2015.
I guess he just found out about it and wanted to let us know.
And, I think you're being a bit harsh about Zig - there's actually significant stuff to be liked. But I still wouldn't use it.
It circles back to the other recent discussion about languages in the Microcontroller section.
-
They just removed a bunch of stuff they did not like and shuffled the syntax a bit.
So it was my-c, at the beginning.
Give them time and you'll see where it goes
-
They just removed a bunch of stuff they did not like and shuffled the syntax a bit.
So it was my-c, at the beginning.
Give them time and you'll see where it goes
I'm not particularly advocating it, but have a look at it instead of having preconceptions and not actually knowing what it is.
It has already gone pretty far.
-
take off every zig
-
One thing I like to use the preprocessor for is to create tables of values that are all derived from some common input. Alternatives would be runtime initialisation (causing slow startup - like many PC programs) or an external code-generator to produce them (so now you've got an infinite variety of preprocessors, according to taste).
external tools must generate code for my-c, so data-type and error-flow are always checked at compile time, and you know which level{1..5} of code they generate, so you can accept or reject.
-
What do you like about Zig?
-
What do you like about Zig?
What do you not like about Zig? Not a trick question nor a way to imply that it's all great. Just a genuine question, it's always better to discuss concrete points.
You can have a look there to see for yourself, if you haven't already: https://ziglang.org/documentation/master/
I think there's a bunch of interesting improvements over C. The comptime stuff is not bad. The syntax - it's ok, it looks obviously heavily inspired by Rust's syntax. Getting rid of the "inverted" C syntax, to get something closer to Wirthian languages, is not bad thing IMO. There's also nice stuff in terms of pointers, vectors, handling of undefined behavior, and the type system in general. The 'defer' construct is obviously handy as well - something we always more or less emulated with ad-hoc constructs in other languages. And, probably a lot more I'm missing.
Now is that enough to switch to a new language? That's always the question.
I personally wouldn't switch, if just because, as with many other newer languages, there is no standard, the language is not clearly defined (if you look at the documentation above, you'll notice that most features are described with examples rather than with text with a clear description and a clear definition), and what makes up the language is really the compiler, which is something I don't like and don't trust. Until you release at least a well-written, and ratified report, it's almost impossible to write another compiler for the language.
Note that these points are not specific to Zig. Almost all new languages suffer from this problem. To me, that's a no-go.
While it's obvious that it will take time before a recent language can get its own ISO standard, one can at least write a fricking language report, ratified by a board of maintainers.
"The compiler is the language", with funky accompanying documentation and a bunch of tutorials, is a major mistake from my POV.
Other than that, Zig has a few interesting features, and contrary to some other new languages like Rust, at least it's not opinionated to the point of near-schizophrenia.
And so, with all that said, no, it won't be the next hype. I could bet some good money on that one.
All in all, even if one has no intention to ever use it, it's always interesting to have a look at it, just like it's interesting to have a look at many other languages, past and modern ones.
Even if just to see what you really wouldn't like in a programming language.
-
Zig existed for a long time
and still
Latest Release: 0.10.1
Eh, ok. What itches is it designed to scratch? -
I wouldn't consider Python a hype considering it has been around for about 30 years.
Professionally I have to deal with quite a few programming languages, and after several decades I've seen quite a few come and go. The success of a programming language does not so much depend on the qualities of programming language itself, but more on the ecosystem around it:
- Availability and quality of tooling (compilers, debuggers, IDE...etc.)
- Available libraries
- Documentation
- Supported platforms
- Size of the community (if only very few people use it it will likely die a silent death)
- Availability of support (commercially, forums...etc.)
- Availability of developers (claim to be) proficient with the language
- Availability of courses
- ...etc.
All that determines much more a how quickly one can realize an idea than the specifics of the programming language itself. -
Professionally I have to deal with quite a few programming languages, and after several decades I've seen quite a few come and go. The success of a programming language does not so much depend on the qualities of programming language itself, but more on the ecosystem around it:
- Availability and quality of tooling (compilers, debuggers, IDE...etc.)
- Available libraries
- Documentation
- Supported platforms
- Size of the community (if only very few people use it it will likely die a silent death)
- Availability of support (commercially, forums...etc.)
- Availability of developers (claim to be) proficient with the language
- Availability of courses
- ...etc.
All that determines much more a how quickly one can realize an idea than the specifics of the programming language itself.
That's not a bad list and conclusion.
I'll add that for me a key question is whether a new tool (kitchen, garden, electronic, software, etc) enables me to do something better than an existing tool. If not, why bother to switch?
A key topic that has been becoming important for a couple of decades, and is now obvious to most people, is parallelism in the form of multiple cores/processors with complex memory hierarchies (caches, NUMA, etc). Given that environment, how is Zig better than existing tools? -
If you want to use programming language for more robust code than C, there is a Rust. For a sweet debugging and code analysis there is C#. For a browser there is JS.
Of course there are a lot of other languages, but in many cases they are not required, because you can write code in C
-
I'm holding out for Zag.
-
Code: [Select]
#define REPLY "The are a lot of languages designed for beginners. But experienced programmers require detailed syntax that does not treat them like they are a newbie teenager at code camp 101."
var controvesy string = $REPLY