167 karma · joined August 24, 2021
> Limit one signup per household. We will use payment method, shipping address, and other information to eliminate multiple entries.
Where in imperative programming languages you supply arguments to a function and get a result in Prolog you can give the result of a function call and get all argument sets that lead to that result.
But you are right that in production systems you would seldom see Prolog, for reason that you can easily LLM.
> Claude Code is running in production across multi-million-line monorepos, decades-old legacy systems, distributed architectures spanning dozens of repositories (…)
So it is optimized for the general case, using robust tooling that works everywhere, especially when large & messy.
That being said, your remark is right and for well organised smaller repo’s there’s better tooing it can and should use. But I think it does, at least Codex does is my case so I guess Claude does it to. For example Codex use ‘go doc’ first before doing greps.
Just a single retina screen buffer, assuming something like 2500 by 2500 pixels, 4 byte per pixel is already 25MB for a single buffer. Then you want double buffering, but also a per-window buffer since you don't want to force rewrites 60x per second and we want to drag windows around while showing contents not a wireframe. As you can see just that adds up quickly. And that's just the draw buffers. Not mentioning all the different fonts that are simultaneously used, images that are shown, etc.
(Of course, screen bufferes are typically stored in VRAM once drawn. But you need to drawn first, which is at least in part on the CPU)
For a historic overview of mathematics with (accessible) formulas I highly recommend “Journey through genius: The great theorems of mathematics”.
There's also another hint:
// THIS FILE WAS AUTO-GENERATED. // CHANGES WILL NOT BE PROPAGATED. // ----------------------------------------------------------------------------
(Of course this could be a result of something having nothing to do with the contents of the file, but maybe the author has to meta library that can generate the types in different languages).
There seems to be fixed-precision variants of the vector types as well which seems to be not available in the .NET framework.
Plus, of course, you can't add your specifics needs to library types (like the fixed precision). They are closed to modification.
I am just guessing, of course.
That being said, it would also make total sense to use the .NET types.
Digital purchases are often subscription based which for physical goods (eg newspapers) is also non transferable (as it does not make much sense). In contrast, “one-of” licences are already transferable mostly. Either because the licence keys is a bearer token or companies support transfer (if you’ve registeted). So you dont accomplish much here, I think, but still I agree it’s a good idea to get the details right and fixed in law.
Only when writing code (and not even that: only when doing final or intermediate checks on written code). When reading the code you don't have to use the tools. Code is read at lot more then being written. So if tools are used, the burden is put only on the writer of the code. If Rust is used the burden of learning rust is put both on the writers and readers of the code.
I should have Googled:
https://www.kernel.org/doc/html/latest/dev-tools/
So many tools here. Hard to believe these cannot come close to what Rust provides (if you put in the effort).
What's the reach here of linters/address san/valgrind?
Or a linter written specifically for the linux kernel? Require (error-path) tests? It feels excessive to plug another language if these are the main arguments? Are there any other arguments for using Rust?
And even without any extra tools to guard against common mistakes, how much effort is solving those bug fixes anyway? Is it an order of magnitude larger than the cognitive load of learning a (not so easy!) language and context-switching continuously between them?
Which leads to adding stuff just for the sake of being of interest to developers. Think kubernetes, microservices etc. Secondly, because the developers are really not interested in the business (problems), they just want to easiest fix they can get away with. Which leads to bloat, as described.
A good test for this are feature specifications: if developers/programmers do not want to write them (or even don't read them with careful attention) then they are not interested in the problem domain of the company. It's an uncomfortable truth.
Another thing I've experienced is that non-technical management somehow wants to see solutions with loads of "technologies" included. I was once asked to give a diagram overview of our IT infrastructure. I agreed mentioning it would be a simple diagram (a reverse proxy, a server and a database). The simplicity of the diagram was frowned upon because if you look at all cloud platforms websites they make you believe that the IT infra for all companies must at least look like that of Amazon and Google.
So it is also a problem of management that does not want to reward simplicity and is victim of the "cargo cult" so eagerly fed by cloud providers.
And luck favours the prepared mind.
I remember dismissing it as a toy back when starting to work professionally with FLTK. Soon I realised I was mistaken; it is excellent to create UI's with for C++/FLKT.
I might be wrong here, but as I understand it "parametricity" means loosely that all instantiations use the same function body. To quote wikipedia:
"parametricity is an abstract uniformity property enjoyed by parametrically polymorphic functions, which captures the intuition that all instances of a polymorphic function act the same way"
In this view, C++ does not break parametricity with "normal" (i.e. non-specialised) templates. Of course, C++ does not type check a template body against its parameters (unless concepts/trairs are used), leading to the problems you describe, but it's a different thing as far as I understand.