Earlier quoted context omitted.
What is "compoper"?
A typo of "compiler", I'm fairly certain.
Surely a compoper makes a new pope.
Exit code of white smoke signals success.
Be sure to run decompope first though.
I like Odin
81–90 of 211 posts
Re: I like Odin
#82I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly.
It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible.
Re: I like Odin
#83When I'm evaluating an open-source project, I always check the quality of its commit messages. I don't care about following a specific format or something, all that matters is whether they are informative or not. Sadly, Odin doesn't seem to pass the test. It's full of commits labeled with just "fix ": https://github.com/odin-lang/Odin/commits/master A few examples of projects with better commit messages: Linux kernel…
That’s a decent commit message style, actually. It would be bad if it was just “Fix”. :)
Re: I like Odin
#84When I'm evaluating an open-source project, I always check the quality of its commit messages. I don't care about following a specific format or something, all that matters is whether they are informative or not. Sadly, Odin doesn't seem to pass the test. It's full of commits labeled with just "fix ": https://github.com/odin-lang/Odin/commits/master A few examples of projects with better commit messages: Linux kernel…
When I'm evaluating the quality of a nuclear plant, I focus on the shape and color of the bike shed.
When I want to discard the opinions of HN commenters I always go for tired, worn-out references that I don’t even understand myself.
A commit message has a function which is directly applicable to the craft of programming and not something auxiliary like the aesthetic properties of a shed used by the bicycle commuters. Though in this case I would disagree with the GP since “Fix ” might be a good enough commit message template.
Re: I like Odin
#85A small but (IMHO) very neat detail is the Pascal-style syntax for defining variables (without requiring a separate 'var' or 'let' keyword): // inferred type: a := 23 // explicitly typed, the type is squeezed between the : and = a : u32 = 23 OTH constants now require special syntax: a :: 23 ...but at least this is consistent with other places in the language, like functions: my_func :: proc(...) ...and 'squeezing in…
This pun originates from Limbo, I think. Go inherits the colon-equals for the inferred-type definition, but not the colon for type ascription, yet another way in which it could have been beautiful but isn’t.
Re: I like Odin
#86Earlier quoted context omitted.
> Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels [to be] systems programming. Since you can write the above with any language, perhaps even Python or Lua if you wanted to, it's not exactly the ability to write the above or the fact of having written the above in a language, that makes a language to be considered a "systems programming languag…
I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming. If you succeed at that, I further challenge you to: find me two concurring definitions of systems programming language that include enough detail to qualify and disqualify languages consistently. By "enough detail" and "clear bounds" i mean: a…
>I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming.
There's no such thing - that was the whole point of my comment.
A systems language is not such because of conforming to a definition, it's a delibarate classification ("this language is, that one isn't" as opposed to "this langauge is because it conforms to this definition"). And that "is/isn't" isn't even up to the individual programmer, it's cultural.
There are characteristics that drive this classification, but it's not driven by a strict definition. It's more of "know it when I see it" kind of affair.
Re: I like Odin
#87Earlier quoted context omitted.
> Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels [to be] systems programming. Since you can write the above with any language, perhaps even Python or Lua if you wanted to, it's not exactly the ability to write the above or the fact of having written the above in a language, that makes a language to be considered a "systems programming languag…
Sure one can play word games all day long if that is your point.
Civilization is all about word games, is my larger point, and those games are important business and what drive characterization - they're not something incosequential that we can "set aside and get to the real work".
Doubly so if what we're concerned about is labelling itself, like "what is and what isn't considered a systems language". Then we're in the word domain, not in the measurement domain.
Re: I like Odin
#88Re: I like Odin
#89Earlier quoted context omitted.
You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap obj…
By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…
An additional tradeoff is that many safe data structures or algorithms are impossible to implement in safe rust. Doubly linked lists being the canonical example. However I feel like the juice is very much worth the squeeze and most rust developers won’t run into these limitations regularly.
Re: I like Odin
#90Earlier quoted context omitted.
Can't tell if serious...
Either a reference to Abstract Machine from the standards, or something suggesting the processor is a C virtual machine.
Interesting article:
"C Is Not a Low-level Language" (https://queue.acm.org/detail.cfm?id=3212479)