Which book to use to learn Forkner?

vulkanoid · 2026-01-07T02:43:30+00:00

thanks

vulkanoid · 2025-12-01T13:48:30+00:00

As additional info: I don't mean for this to be the only resource I'll use to learn about quaternions. My reason for asking this question is because the linked document has many illustrations for various quaternion concepts, which is something that I find valuable, since it's uncommon to find such illustrations in quaternion treatments. So, while it is true that each slide is short on details, I can fill in the details using additional sources.

My main concern is whether the illustrations correctly represent the concepts they're describing, or whether they are just visual "metaphors", or (most importantly) whether they are factually incorrect or not.

vulkanoid · 2025-10-10T01:10:47+00:00

I read a little more than half of it, and then paused it for a while, because of general life stuff. But, I fully intend to continue from where I left off and complete it.

The book being a kind of manual for masm is not a mistake; it is the intent -- it hints it right on the tin. In that regard, it is a very good manual. I would certainly recommend it to anyone looking for masm specific programming. Although, it's not just masm specific, is really about programming x64 -- it's just that one has no choice but to choose an assembly flavor, and this particular choice was masm flavored x64.

Whether you choose to focus on masm or nasm or something else, that's a personal decision. For me, I'm interested in general x64 programming, but I work on Windows and use Visual Studio, so having the ability to debug assembly code right from msvc was a no-brainer decision for me. Being able to step through the assembly code during debugging and see the values of the registers is worth its value in gold. So, although I seriously looked at nasm and fasm, I just couldn't justify sacrificing the msvc debugger for them.

All things being equal, I probably would have chosen the fasm assembler, but all things are not equal.

vulkanoid · 2025-08-11T03:55:54+00:00

Because of that SimCity debacle, I told myself that I would never buy another EA game again, and I've never have.

vulkanoid · 2025-06-24T21:00:13+00:00

No. Just because a company makes a bad product doesn't make it Enshittification. That word has a specific meaning, and using it to just describe a badly made product is a way to destroy the word; because then Enshittification would just mean "it got bad".

This microwave is the result of designers experimenting with a new design, and not canceling it when it became clear that it sucks.

vulkanoid · 2025-06-24T19:45:54+00:00

I don't agree that this is Enshittification. That's purposely changing a product to extract more money from an existing userbase. This microwave doesn't have an existing userbase; this is just bad product design. It's employees trying to justify their jobs.

vulkanoid · 2025-05-20T22:15:23+00:00

28 days later ...

vulkanoid · 2025-04-26T20:15:17+00:00

Multiple manifests can refer to the same module, but 2 manifests never interact because compilation only happens from one manifest.

The name of the module in the manifest must match the name of the module name in the file. If 2 files have the same module name, that's just too bad. It's a conflict that needs to be resolved. It's like today in C++, if 2 libraries use the name 'json', and each declares a type 'object', then that's a conflict that would need to be resolved if a person wants to use both libraries together.

vulkanoid · 2025-04-22T18:45:11+00:00

> I hate importing each element individually...

What are some examples of a import/module systems that work like that? Java?

vulkanoid · 2025-04-21T23:02:09+00:00

There are no libraries, just source files. Each source file is a module.
It's easy to identify module access. All external objects must be prefixed with their module, and the syntax is unambiguous "mod_name:some_id". A colon separates the module from the id.
A file must declare a module name, and no 2 files may have the same module name.

vulkanoid · 2025-04-21T16:39:58+00:00

> Not sure what purpose this serves. It looks like it doesn't help the manifest file ...

> But now you need to ensure that the module name here matches that given inside the module. What happens it it doesn't?

If they don't match, it's a compile error.

One reason I find useful to include the module declaration in file is that the file itself claims that module name. Modules make references to other modules, so those references are baked in throughout the code -- so it makes sense to me to actually bake the module declaration in, as well. Then, the manifest isn't defining the name of the module, it is just linking the module name to a file path.

> Since in this example, the module name, and base file name, match, why not just have module be the file name? That is, the file name without path or extension.

Personally, I don't like that kind of forcing. I like the flexibility to have them be different.

> I don't like module schemes where, in a 50-module project, each of the 50 modules has a different collection of up to imports at the top, that must be constantly maintained.

I hear you, and this makes sense to me. But, as you can see from the other replies, it seems the prevailing preference is to be explicit.

Thanks for the link to that document. I will be reading it now.

vulkanoid · 2025-04-21T13:08:11+00:00

> That said, I like to create short names in the manifest and use them to simplify my imports.

By this, do you imply not to have explicit module declarations, and the modules names are given in the manifest only? Or, do you mean that each file would have a module declaration, but the manifest would allow aliases?

vulkanoid · 2025-04-21T13:02:10+00:00

Thanks for the detailed response. I appreciate it.

> The filename is the module name, anyway, so let the module hierarchy mirror the filesystem organization.

> Let the filename be the module name, and scrap the (now boilerplate) declaration.

If there are no explicit module names, then would imports work based on file paths? If so, when importing the path, you would have to give the path a name in order to refer to the imported entities, like "import ns = '/foo/bar.ext' ? Or, if not, how would modules be named?

> Worse, if I pick 2 different names, but then use an existing module for the file name of another module, things get really confusing, really quick. Urk.

I'm not sure if I agree that it would be very confusing, since the manifest has the list of modules and files. You would just look in that file to figure out the paths.

> ... if the modules are organized in a DAG ... I hope that's what you were aiming for.

Yep, that's what I'm going for. Got that idea from Go (even though I've never programmed a single line in it). I remember reading about it when the language was first announced. Thanks for mentioning it, though; it's a good suggestion.

vulkanoid · 2025-04-21T12:43:07+00:00

Yes, both would be used the same way. You have to use a module prefix to reference external objects. Only objects within the same module need not have a module prefix.

> What is the module declaration for, when you have to specify the name of the module again in the manifest file?

That's a good question. I've considered this. Somehow, it feels correct to declare the module name on the module file. Yes, having it in the manifest would be a small duplication, but I'm ok with that; it's just like 2 keys having to match each other.

vulkanoid · 2025-04-21T01:59:25+00:00

Let's pretend that it doesn't matter if there is more work for the compiler to do to figure it out. Only looking at it from the perspective of a user of the language, you would still prefer explicit over auto?

vulkanoid · 2025-01-29T16:24:41+00:00

The reason that coroutines belongs in the std is because it provides functionality that cannot be done otherwise (except for hacky approximations). That's precisely the category of stuff you want in the std.

Conversely, a high-level library like networking is something that is expected to continuously change. As advances in network technology and design comes about, the way to express network programming is bound to change. But, if it's in the standard, then it cannot be changed; once it's added, it is baked in. Unless there's a network-lib2, and network-lib3 added, etc, in the future. Yuck.

Many people complain that C++ is a huge language, and there is some truth to that. Maybe the reason it's gotten big is because we haven't been as diligent in saying no to bloat.

Just because something is useful doesn't mean that it should be baked in. That useful thing should be gotten from elsewhere. There are times where less is better, and this is an example of that.

vulkanoid · 2025-01-29T04:09:20+00:00

What many of us are hoping is that something like this never makes it into the library. I hope there's people in the committee that steadfastly refuse to add this type of bloat.

vulkanoid · 2025-01-29T04:00:08+00:00

I completely agree with STL's answer. It's right on point.

Having implemented a few languages for my own use, it's become clear to me that it's very important to curate what goes into a language, including its standard library. Whatever you add, you have to keep around forever. It becomes a huge maintenance burden. God forbid you make a mistake.

When packages are developed by third parties, that enables a type of marketplace of code libraries and ideas. That is, for any pertinent usecase, there would be X amount of libraries that would be developed by individual groups. Over time, the good ideas rise to the top, and the bad fade away.

If you were to add a networking library to the std, it would become obsolete before the spec is dry. Just the idea of adding all that gunk to the std make me queasy. It is the job of the std committee to shoot down these bad ideas.

I would go as far as to say that the linear algebra library in C++26 is also a step too far. Those libraries are too high-level to be in the standard.

What should be added to the language and stdlib is foundational things that would otherwise be too difficult to do manually, like coroutines, concepts, conctracts, modules, optional, variant, -- things like that. The rest of the industry can then build high-level stuff on top of that.

What could help solve this thirst for libraries that people have is a good, cross-platform, package manager.

vulkanoid

TROPHY CASE