Prolog is for logic what inverse kinematics is for robotics.
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.
Software engineering is only about 20% writing code (the famous 40-20-40 split). Most people use it only for the first 40%, and very succesfully (im in that camp). If you use it to write your code you can theorettically maybe get 20% time improvement initially, but you loose a lot of time later redoing it or unraveling. Not worth bothering.
Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.
Yes, but then the GPU needs that amount of ram, so it's fairer to look at the sum of RAM + VRAM requirements. With compressed representations you trade CPU cycles for RAM. To save laptop battery better required copious amounts of RAM (since it's cheap).
> Coyuld anyone summarize why a desktop Windows/MacOs now needs so much more RAM than in the past
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)
Concurrent programming is hard and has many pitfalls; people are warned about this from the very, very start. If you then go about it without studying proper usage/common pitfalls and do not use (very) defensive coding practices (violated by all examples) then the main issue is just naivity. No programming language can really defend against that.
Maybe the real reason is more related to Price’s law/Pareto’s principle, loosely meaning that 90% of the work is done by 10% of the people. In other words, in large companies most perons do not contribute much, at least not at the same time.
Anyone knows what does "native" means here precisely? Steam Deck has a x86-64 instruction set AFAIK, so it's just same as a the Windows version? Or has it to do with the GPU / OS? Or does it just mean "properly configured"?
If this thinnest iphone air has 27 hours of video playback, why does the regular iphone 17, which looks twice as thick only has 30 hours? At this point, I just want long battery life. Like an "all-week" battery life would be a nice start.
Well, I use it before google, since it in general summarizes webpages and removes the ads. Quite handy.
It’s also very useful to check if you understand something correctly. And for programming specifically I found it really useful to help naming stuff (which tends to be hard not in the least place because it’s subjective).
It’s a clever trick. But can it render a textured text? Transparent text, gradient fills? Maybe it can, I dont know. But why not just triangulate the glyph shapes, and represent each glyph as a set of triangles. This triangulation can be done offline, making rendering very lightweight.
I wonder, in reality, if a Lua program uses large (consecutive) arrays, its values will likely have the same type? At the very least it is a common use-case: large arrays of only strings, numbers etc.
Wouldn’t it make sense to (also) optimize just for this case with a flag and a single type tag. Simple and it optimizes memory use for 98% of use cases?
I suspect it's part of the fun? A way to really learn something?
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.
I don’t find your “seasoned developer” version ugly at all. It just looks more mature and relaxed. It also has the benefits that you can actually do error handling and have space to add comments.
Maybe people don’t like it because of the repetition of “data =“ but in fact you could use descriptive new variable names making the code even more readable (auto documenting).
I’ve always felt method chaining to look “cramped”, if that’s the right word. Like a person drawing on paper but only using the upper left corner. However, this surely is also a matter of preference or what your used to.
> Limit one signup per household. We will use payment method, shipping address, and other information to eliminate multiple entries.