Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Macro Reflection in Zig

jstrieb.github.io

Post reply on HN
Print view View original

131–139 of 139 posts

Re: C Macro Reflection in Zig

#131

Post by mst »

WalterBright wrote: post #110
throwawaymaths wrote: post #99

Earlier quoted context omitted.

Compiler giving a compiler error still favors the writer, not the reader of code. It seems like in its design in general D favors the writer of code with all its complicated bells and whistles that one must keep in mind as a reader. I think decades of experience has shown us that it is way better to favor the reader.

You can do it either way in D. It's nice to have a choice! I use both methods, depending on the context.

Seems like "if it's obvious where it came from, use the unadorned name, if it'll be non-obvious to a future reader, use the more explicit form" is a solid heuristic and letting the programmer decide is a feature.

(it might be worth having some sort of lint option that will flag using the non-explicit form because I can see large multi-developer projects finding it preferable to add 'use the explicit form' to their local coding style ... but I don't have a dog in this fight so 'free thought, worth exactly what you paid' applies ;)

Re: C Macro Reflection in Zig

#132

Post by mst »

flohofwoe wrote: post #122
classified wrote: post #120

Thank Apple for Reader View in Safari. If you are as incompetent in visual design as the author of that page, you should really stay away from dark mode. Your readers will thank you.

What's wrong with green-on-black? I'll take that over amber-on-black any day even if amber is apparently better for CRT burn-in.

I tend to use green on black for daytime hacking and amber on black in the evenings to reduce blue light issues.

But I also habitually run with jacked up contrast and nerfed brightness, so I make no claims that what works for me would be a good idea for anybody else.

Re: C Macro Reflection in Zig

#133

Post by bluGill »

3836293648 wrote: post #105
bluGill wrote: post #65

Earlier quoted context omitted.

C++ fears getting reflection wrong, which is why it takes a long time to get it in.

C++ fears getting lots of stuff wrong, which is why they got rid of good concepts, waited 20 years and then added bad concepts

It was only 10 years between getting rid of concepts and getting the replacement in.

They got rid of "good concepts" because when attempts were made to implement them the build for a simple "hello world" was over 15 hours and the implementers didn't think they could optimize that enough to have acceptable build times. As such I wouldn't call what they got rid of good concepts - to be good it needs to be nice not just in an academic paper, but also in the real world.

Re: C Macro Reflection in Zig

#134

Post by samatman »

jay-barronville wrote: post #117
samatman wrote: post #115

Earlier quoted context omitted.

We have different ideas of what a big deal is, clearly. The idea that C programmers, C programmers , are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible. The complexity has moved to a slightly different place. That's it.

> The idea that C programmers, C programmers, are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible. What I find incredible about these takes is that they’re so removed from reality. It’s quite unfortunate how difficult it is to get a lot of programmers to evaluate things from the shoes of others. I have firsthand experie…

I think there are several things going on here:

- You're used to the way it works now, and don't like that it's changing

- The build system is woefully underdocumented (understandable, since it's new and hasn't stabilized, but it's not a good thing), and you're conflating that with the system being hard to understand, which it isn't.

- You're combining these things, and your inflated sense of how well you know every C programmer in existence, into a claim which, again, I consider risible.

Because you're saying things like this:

> There’s a reason why Zig has been marketed as a compiler that can also serve as a drop-in replacement for GCC/Clang. What you’re effectively saying is that this main selling point doesn’t matter even though that’s been one of the main things that makes Zig attractive to C programmers. Incredible.

Which is a bizarre thing to derive from what I said, and is also absurd. Andrew wants Zig to be the best way to build C, always has, and he's the one responsible for making it as good as it is. His goals there haven't changed, what's changed is how he intends to provide that.

Now, you can claim, and you have, that he's going to make it much worse in the process. But your reasoning for saying this is thin and I disagree with that premise completely.

Re: C Macro Reflection in Zig

#135

Post by markus_zhang »

winrid wrote: post #119
markus_zhang wrote: post #42

Earlier quoted context omitted.

I have never used Clion. Can you please share why you believe it is the top of the crop? I'm writing a C++/SDL2 game engine in Visual Studio but I think the IDE is really slow and error prone even for a small project. Everything just runs so slow. Maybe I need a better machine though.

CLion has a free trial you can try. I find it works really well. I use it on a 6yo laptop quite often for C++.

Thanks! Just to confirm, are you using Windows?

Re: C Macro Reflection in Zig

#136

Post by winrid »

markus_zhang wrote: post #135
winrid wrote: post #119

Earlier quoted context omitted.

CLion has a free trial you can try. I find it works really well. I use it on a 6yo laptop quite often for C++.

Thanks! Just to confirm, are you using Windows?

I use it on Windows and Linux for game development, mostly, with Meson or Cmake.

Re: C Macro Reflection in Zig

#137

Post by voidUpdate »

MobiusHorizons wrote: post #73
voidUpdate wrote: post #36

Earlier quoted context omitted.

My terminal editor of choice is nano :P

It sounds like you have two editors at least, vscode and nano. Based on this description, I would assume you use nano for commit messages, config file updates, and not much more. If that’s the case, you may want to at least check out what emacs or vim can do for you with some basic lsp integration. These would be replacements for vscode not nano, although once you get used to them, you might switch EDITOR over. Compa…

My terminal editor of choice is nano. I do quite a bit of document writing, programming, config file updating etc in nano when I'm on a system without a GUI, but if I'm on something with a proper GUI, I tend to use VSC for script writing. I've attempted to use vim before but the different modes and all the key combinations and shortcuts went in one ear and out the other. I barely remember how to exit. Nano has always just seemed more friendly to me, like "oh you want to write a file? Here's a text buffer, ctrl+x when you're done with it"

Re: C Macro Reflection in Zig

#138

Post by throwawaymaths »

jay-barronville wrote: post #103
throwawaymaths wrote: post #102

Earlier quoted context omitted.

I "don't know" because zig 0.14 is not released yet and anything could happen but I DO know that imports do not currently require the build system. And I THINK that's because the core parts of the build system (including binding imports) are dependent on the command line anyways. So I am ASSUMING that property will be invariant when the c @import gets implemented, and my "don't know" is merely being explicit about th…

> You are the one coming from a place of ignorance here, and your refusal to acknowledge that you might be wrong makes me suspect your argument is not being made in good faith. You’re making a lot of “assumptions” when you could just read the GitHub issue regarding this change, written by Andrew himself, titled “move @cImport to the build system” [0]. By the way, please note that I not only write Zig code almost dail…

Andrew responded in that thread to some more recent comments and made it clear that it will be possible to do all the things from the client without build.zig, (apparently not in one command though)

Re: C Macro Reflection in Zig

#139

Post by throwawaymaths »

TwentyPosts wrote: post #109
throwawaymaths wrote: post #96

Earlier quoted context omitted.

I think you are operating from a mistaken understanding, as responded to in the linked comment.

Andrew (in the linked Github page) answered a question as follows: > Question: "So after this change, is there way I can still simply call zig run or do I have to use a build.zig file?" Andrew's answer: "No, this use case will regress." This in fact literally states that "just" calling "zig run" won't be possible anymore, and heavily implies you'll need a build.zig file.

After some more recent comments,

> This in fact literally states that "just" calling "zig run" won't be possible anymore,

This seems correct.

> and heavily implies you'll need a build.zig file.

This seems to not be the case.

Post reply on HN