I learned how to put various data in classes and manage them structurally through trial and error in JavaScript
But I was able to do this because JavaScript has “hoisting”
When I tried it in Python, it didn’t work well
This is the coding style I came up with to solve this problem
I transferred it to Zig as it is
If you’re interested, please take a look
I have no idea if the non-english comments provide an in-depth explanation, but from the code (without understanding the language in the comments) it seems like a bit of organizational structure and it is hard to understand more than that.
I think using namespaces and functions to structure things can be helpful.
Using inline for all these functions seems excessive and unnecessary, why are you using inline so much?
I don’t really agree that following such a structure is generally useful and helpful (it might be helpful sometimes), I think it can lead towards unnecessary boilerplate in many circumstances.
I think if you decide to use this structure in a project that actually does something, that may illustrate your point better.
Personally I dislike these kind of presupposed organization patterns, because different problems have different ways, in which they can be written, without adding unnecessary complexity to the problem.
Imposing a rigid structure is likely to not actually serve a purpose beyond enforcing that structure, I don’t think that regularity is useful in itself, it needs to be there for a reason beyond somebody wanting it out of personal preference (well you still can choose it out of that reason alone, but I guess then it is just a matter of personal taste).
I am truly sorry.
I assumed that even if I left it in Japanese, it would be fine if I put it through a translator, so I added English translations using ChatGPT and Google Translate.
Also, the reason for using inline in Flow, App, etc. is very clear, so I added that as well.
Could you please read it again?
And, It seems there may be a conceptual gap between us regarding the use of inline.
To clarify: I am treating inline not primarily as a performance optimization hint, but as a mechanism similar to macro expansion (code expansion at compile-time) essentially from a more assembly or structure-oriented perspective.
In typical usage, inline may imply “this function might be optimized for speed.”
However, in my case, it is a logical indicator, meant to explicitly control code placement and expansion in a structural way.
In my design, App and Flow are not “functions” in the traditional sense.
They are structural separators like named document sections designed purely to organize and clarify the flow of logic in a visual, human-readable way.
Thus, these inline fn declarations are not meant to be reused, nor intended as conventional functional abstractions.
Their purpose is code segmentation, structure clarity, and inline expansion for predictable behavior, not “speed” per se.
From a compilation standpoint, not using inline here could increase unpredictability in layout and flow, and potentially impact the readability and logical determinism I am aiming for.
So, this is not an arbitrary stylistic decision, nor a naive attempt to “speed things up.”
It is a deliberate and theoretically reasoned design choice, aiming at deterministic structure and clarity in the compiled form.
Apologies if the original presentation gave a misleading impression.
And, I would like to clarify that the code I write is fundamentally constructed through logic and theory, not intuition or trial-and-error.
Each part of the code is deliberately and carefully structured based on logical reasoning.
That is why I would truly appreciate hearing your thoughts and insights on it.
I’m still relatively new to coding in Zig, and I have been compensating for gaps in my understanding by applying my own logical framework rather than relying on full knowledge of the language’s inner workings.
Because of this, I do not yet examine every line of the Zig compiler or its standard library source code in detail.
So if you do have a deeper understanding of the actual processing mechanisms or conventions in Zig, it would mean a great deal to me to hear your informed perspective.
I would be very happy and eager to discuss and refine the ideas, especially from someone who has concrete understanding of how Zig works internally.
I’m truly glad to have received a reply from you, thank you very much.
I understand that you used Google Translate to detect the language, but it seems that you chose not to read the translated content directly.
I imagine this may be due to past experiences with Google Translate providing low-quality results for Japanese, and I can completely understand that as a precaution.
It’s a thoughtful and considerate approach, and I sincerely appreciate that level of care.
However, please allow me to make a small correction:
Today, Google Translate has become considerably more accurate when translating from Japanese (though it may not always produce natural English).
Furthermore, if you use tools like ChatGPT to assist with the translation, I believe you can get even more accurate and clear results.
Please understand that I say this not to criticize or diminish your approach.
In fact, the fact that you took the time to respond suggests to me that you’re a very kind person and I sincerely appreciate that.
I quickly prepared an English translation, but since it’s clearly too long to include directly in the code, I’ve placed it here instead.
I add to code that recommend of using a translation tool such as ChatGPT if needed.
// English Version
// This is a document written in ChatGPT, but I have also included some auditing from me. If you have any questions, please raise an issue and we can discuss it.
// # Design Philosophy
// ## Fundamental Philosophy
// Aims to achieve complete logical control and prevent undesirable outcomes such as misinterpretation.
// ## Naming Conventions
// - For function arguments, please start variables with an underscore `_`.
// - Example: `aaaaBbbbCccc_Eeee`
// - For functions or structs, start with an uppercase letter.
// - Use `Aaaa.Bbbb()` instead of `AaaaBbbb()` where appropriate. This is to make the structure clearer.
// - For internal implementations or language-level elements, start with an underscore (`_item`, or `const _Standard = @import("std")`, etc.).
// ## Performance:
// - Performance should be guaranteed by the *language side*, such as through inline expansion.
// - Instead of storing precomputed values as part of the algorithm, use `comptime` wherever possible.
// - Functions that are only used once in the flow should be inlined to ensure performance.
// - If the optimized version of an algorithm in the actual code becomes difficult to understand, please add a comment explaining what kind of algorithm it originally is.
// ## Variants
// - If the implementation changes depending on architecture (e.g., AMD64, Intel64, RISC-V, ARM), it is recommended to separate the logic into a different library to distinguish between *variants*.
// - The idea is that abstraction is still possible via common functions.
// # About the Structure of This Code
// ## App & Flow
// As can be inferred from the above, the two structs `App` and `Flow` are intended to function as *section markers* in a document. In other words, they are *not meant to be used as functions*.
// If you were to treat them as executable functions, Zig’s compiler might perform optimizations (such as size reduction) in unintended ways.
// To prevent this, we explicitly use `inline` as macro-like expansion to indicate: “this is not a function, it’s just a code snippet.”
// The `main()` function appears at the bottom of the code and runs `App.Origin`, which achieves behavior equivalent to hoisting. Since the compiler interprets everything beforehand, it executes properly without issue.
// As noted above, these are *logical separations*, so `main()` is assumed to have `App.Origin` fully inlined.
// For the functions inside the `Flow` struct, be sure to give them names that clearly describe what they do. This is essential. This is the main reason why we use a flow-based structure.
// ## Code
// The `Code` struct is a workspace where you may freely place libraries and tools.
// `_Standard` refers to the *language-side standard*. We avoid naming it `Standard` directly to prevent overriding your own definition of what constitutes “standard.”
// You are free to define your own library as `Standard`, according to what makes sense for your project.
// ## Alias
// Please use this as a place for aliases and shared variables. If you are building libraries, threads, or communication systems, it's preferable to route them through `Alias`.
//
// # About Future Plans
// ## App
// The reason why `Origin`, `Exam`, `Document`, etc., are separated is originally because each was intended to accept distinct command-line arguments.
// Here are some example commands:
// - `% App`
// Executes `App.Origin`
// - `% App Exam`
// Executes `App.Exam`
// In short, the initial argument determines which part of the structure (functionally) to execute.
// However, I am still unsure what the best algorithmic approach for this would be, so the current setup also allows you to change build-time requirements externally, or use this for development or as a storage location for flows.
PS:
Translation is truly exhausting and requires a great deal of effort.
It also involves the need for corrections due to potential misreadings, and above all, the responsibility for those misunderstandings ultimately falls on me the original author.
I would be sincerely grateful if you could consider using a translation tool when reading.
I kindly ask for your understanding and cooperation on this point from now on. Please…
Thank you for taking the time and explaining in more detail.
I was vaguely getting that impression, but chose not to assume and instead just ask what you are doing with all the inline. Your description explains it well.
Are you essentially using Zig syntax in a prescribed way that conforms to an implicit ruleset? I think what you describe could be called a framework for structuring Zig code in a particular manner, to achieve certain structural goals of that framework.
Personally I am not a huge fan of these implicit rulesets that emerge from using a language in this way (I sometimes do this, but I try to avoid it), I prefer it when these rules actually become explicit by being implemented and enforced by code, instead of by rules that need to be followed by me manually.
Essentially when I encounter these things, I begin to wonder “are we still writing Zig here?” or is this a new language dialect, that tries to hide itself as if it was a normal Zig program? And it begs the question, should this be like a dsl that is embedded inside the existing language constructs, or would it be better as something that gets implemented explicitly as a language?
Here is my approach:
I create a piece of code, some data and some functions operating on it, now I have something concrete I can run, debug, log things on, maybe while writing it or running it, I discovered a bunch of things I hadn’t thought of, leading me towards learning more about it. So that is one nice little experiment, either it goes well and just works like I had hoped, or I get a bunch of errors or insights I can learn about.
Then when I have created a bunch of these, I can think about different combinations of these experiments, could I:
compose 2 of them?
use one inside the other?
generate data with one and communicate/transport it to the other?
make my implementation simpler/remove something from it
make a small change so that it is easier to compose with something else?
Personally I find approaching this from a strong focus of theory, not so helpful.
(Sure in areas where you have a lot of experience, you can think through a bunch of variations in your head without trying each, but personally I can do that only to a certain depth and afterwards my head begins to spin, because the number of possibilities is eventually to big and the problem becomes too abstracted and disconnected from practical concerns and implementation details)
So while I use theory, logic and reasoning at different times within that process, I think: practice, exploration, experiments, visualization, debugging, testing, logging and even trials and fuzzing and all that kind of stuff is useful too.
The question is more, what do you have time for and how do you invest your time wisely. So what approach is a useful strategy in the situation? (And that can be quite difficult to answer)
I have a good, but certainly not a full understanding of Zig’s inner workings.
While having your own way of doing things can be helpful, I wonder whether, if you rely on one particular way of doing things, if that can become a sort of crutch that becomes an entrenched habit, of solving every problem in one specific way.
I think it is good to keep a beginner mind set and every once in a while try to do things in new and different ways, just to see how it turns out and have some different experience you can compare it with.
me neither
I have some more or less vague knowledge about how Zig works internally, I want to deepen my knowledge about that over time and there are some great posts about how specific details work in this forum, but currently I am still more focused on using the language in different ways, than actually working on the language itself, or understanding all the details of its implementation.
I read it a bit, but it didn’t fully click with me and I was unsure, whether that is because I am missing context, or whether the translation was missing things and trying to speculate too much isn’t helpful, when you aren’t sure.
I don’t have a lot of experience with using translation tools with languages, where I am not familiar with the basics of reading at least some small subset of the language.
It is not that I don’t trust it, I just dislike not being able to verify it myself and thus I would rather ask a person to clarify, instead of assuming the tool worked correctly or that I understood correctly.
After reading your response, it seems to me that there is a discrepancy between us regarding the “rules” or “laws” that govern this discussion.
My code was written with the intention of fulfilling what I believe to be the true objectives of Zig:
" Explicitness — that is, to express logic in a way that is structurally clear and flow-based, without needing comments, instantly understandable to readers, and absolutely immune to unintended behavior. "
" Determinism — meaning that the output is fully predictable and that the logical structure and execution flow are unequivocally defined. "
However, I get the impression that you are instead using the principles that emerged as means to achieve these goals as your primary criteria, rather than the goals themselves.
Indeed, my approach does propose concrete solutions that may not have been part of Zig’s original development path, but it should be obvious that these principles were formulated after the core objectives were identified. Therefore, I believe it is not ideal to prioritize those derived principles over the original purpose itself.
I would like to begin by clarifying what the correct basis of evaluation should be.
Put simply: if the underlying premise is flawed, the theory built upon it is inherently inconsistent.
I believe examining and verifying that premise should take precedence.
(Just to be clear, I do not want to be an enemy, but rather to have a useful discussion.)
PS: There was also the matter of robustness. I will add that to further reinforce my point.
You talk in quite abstract terms, I am not really interested in having a formal debate, that is rooted in mathematical proofs, category theory and verifiable logic terms.
I think if you want to do that, you might as well interact with an actual theorem proofing system, I don’t have practical experience with those, but I have heard that they can be quite interesting and that they can be used to verify things in a way that makes everything super rigorous.
Personally I would rather approach it, from a less serious standpoint, of building something I enjoy, brings me fun, allows me to learn and can be improved by me, incrementally.
I am not here to tell you you are right or wrong, I am just here to share my experience and perspective and what has worked well for me.
I am not super into the approach of total correctness from the top down, from the start. I would rather follow things in a way that allows for a more relaxed, evolutionary process.
Just as a note, your scaffolding may be perfect, but it also currently doesn’t do anything at all, it is just structure all the implementation parts are elided, left as an exercise to the reader.
Personally I think the implementation parts are the details that really matter and when you understand those you can shift around and change the structure of how the pieces interlock together.
But this discussion is becoming a bit to philosophical, for my taste, at least for a programming forum.
Why did you come here in the first place?
(This is not a provocation. Please read the article to the end!)
I honestly cannot understand your purpose.
Perhaps you are under the misconception that if this template spreads, your coding style will become unusable?
In reality, what I am proposing is “the ultimate code template that every programmer dreams of—one that guarantees no negative legacy will ever arise and fulfills all objectives in the future.”
If you want to code for fun, of course that is not a problem. In fact, I believe that if enjoyment is your motivation, then it’s all the more reason to firmly protect the boundary between that and serious discussion.
However, you are not attempting to follow the logical ‘protocol’ of this context.
I am conducting this as a discussion space.
A discussion, by nature, is a framework constructed by individuals bringing their own logic systems into contact—formed based on shared variables and evaluation criteria—and verifying their internal consistency.
It’s not about politeness or formality; it’s about validating logical coherence.
If that purpose is misunderstood, the result will be the emergence of a “corrupt democracy”—a system drowned in favoritism and bribery, where anything goes. That is exactly what must never be allowed to happen.
I pledge to absolutely protect the sanctity of logic and never allow it to be compromised.
That is non-negotiable. This is my conviction.
Also, I am not talking about philosophy or abstract ideas, but rather about a logical framework I call the “Destiny Theory,” which is based on dependencies derived from objectives.
Its purpose is to process what I see as the “final theory structure” in this discussion environment, driven by a variety of explicit goals.
Of course, there are still many parts I haven’t formalized, so this doesn’t mean I claim omniscience.
I am simply a human being who seeks to share variables (i.e., information) with someone as kind and thoughtful as you, build a verification function together, and through it, create real executions and improvements.
That’s all I truly wish to do through this discussion.
(“Destiny Theory” is a theory I developed for my operating system called RW.
It enables execution by gathering the elements necessary to fulfill a purpose (“Destiny”), a process I call a “Destiny Shrink.”
There are several variants of Destiny Shrinks.
Just to clarify: RW is a word I independently defined; it is neither “Read/Write” nor “Real World.” It is a standalone term specific to this OS.)
While I understand that my framework is logically intense, without such a shared epistemological foundation, I don’t believe a meaningful discussion can occur.
From your reply, I infer—based on theory—that you don’t wish to engage in proper discussion, and instead are trying to operate only on your own terms of acceptance or denial.
This likely stems from not having a precise definition of what constitutes “discussion.”
Since I primarily use Japanese, I utilize its linguistic structure.
Unlike English, Japanese grants precise logical definition to each individual character (kanji, hiragana, etc.).
As long as those definitions aren’t arbitrarily misused, they provide an absolute foundation from which words can be formed and utilized.
I apply pressure to those definitions, match them with my theory, and establish a strictly coherent logic system of my own—making every effort not to let fallacies or invalid variables slip in.
Frankly, I’ve never seen anyone else do this, but I believe it’s necessary.
That said, I am not demanding that you do something similarly extreme.
I simply hope that you maintain a posture of constructive dialogue aimed at making things better.
Also, I truly appreciate that you’ve continued engaging in this discussion.
I’ve stated many times that I do not wish to attack you—and I mean that with all sincerity.
Trust is essential in communication.
It’s much like why Arch Linux’s AUR doesn’t distribute precompiled binaries and instead requires compiling from source.
It’s because humans can’t fully audit or grasp all logic at all times, and so anxiety arises.
Trust resolves that anxiety.
It is through trust that emotion is implemented by logic, and logic is activated by emotion… This is one example from my theory.
So please understand—I am not speaking abstractly.
What I dream of is to make everything useful and meaningful—an ideal state for this world.
That is what I am striving to realize here and now.
Would you be willing to cooperate with me?
Logic does not mean the rejection of emotion.
PS: I write down the definition of the Japanese version here so that someone in Japan won’t mistranslate it later.
I’m starting to wonder…
Is this community not necessarily a place for strict or rigorous logical discussions about Zig, but more a space to enjoy the language together and grow in a relaxed and friendly way?
When I saw other threads, I saw very kind and thoughtful people like you having sincere and serious conversations. So I thought I should try to contribute by applying the highest level of logic I could offer.
But if this wasn’t the right context for that, then I sincerely apologize.
Edited: (ChatGPT Translated)
I now understand. I had not explained all the dependencies underlying my logic up until now.
It is only natural that others could not fully grasp what I was saying. This was a failure on my part. I am truly sorry.
However, the amount of prior knowledge I have built is vast, and to prepare the foundation required just to begin a discussion is mentally exhausting for me.
I would be forced to explain, over and over, an enormous and highly structured logical system that functions as a substitute for mathematical formalism.
And even if I manage to do that, it would only enable us to discuss relatively small matters in comparison to the scale of what must be explained.
While the main topic of the discussion is indeed important, the effort required on my part is overwhelmingly burdensome.
To continue would mean I have to repeatedly and endlessly attempt these explanations.
This is beyond what I can endure.
Therefore, I would like to step away from this discussion.
It seems we have reached a point where dialogue is fundamentally no longer possible.
I cannot bear the future I foresee — one in which I must repeatedly take on this excessive labor.
Please understand, this is not because of any fault in those who may read this, but entirely due to my own mental limitations.
