marhee

They do:

Limit one signup per household. We will use payment method, shipping address, and other information to eliminate multiple entries.

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.

The answer is in the introduction:

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)

I will definitely reads these books when they come out.

For a historic overview of mathematics with (accessible) formulas I highly recommend “Journey through genius: The great theorems of mathematics”.

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.

If you enjoy this art-style, definitely check out the game Return to the Obra Dinn.

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.

Would be quite funny if Apple now acquires OpenAI.

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.

According to that logic, why not distribute fluoride water freely for those who want it? That would serve boths camps, not?

* Digital “purchases” are transferable…

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.

but it's time-consuming and cumbersome to say the least

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.

You can't valgrind kernel space Linters might be helpful, but I don't remember there being good free ones

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).

The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C .... Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes.

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?

The main reason for bloat not mentioned in the article is that most developers are not interested in the business domain of the company they are working for. They just want to do stuff with computers and software.

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.

13. “Audentes Fortuna iuvat.” (Fortune favors the bold).

And luck favours the prepared mind.

Regarding the immediate effect I am sure your point is valid. But it’s also a bit of a cynical point of view, wouldn’t you say? People make these statements and pursue these personal lifestyle decisions because of their dreams for a better future - not its immediate effect. Just as companies need a vision to succeed, societies need vision as well. If a lot of people are vocal about something and live it, it has a chance of becoming anchored in laws and so force companies to do the “right thing”. Regulation follows collective values.

A mature (and very effective) structural editor is the FLUID user-interface designer, part of the FLTK UI framework (C++). It outputs C++ and works very well.

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.

C++ breaks parametricity even with normal templates

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.

Interesting points.

Implementing generics in this way breaks parametricity. Simply put, parametricity means being able to reason about functions just from their type signature. You can't do this when the function can do arbitrary computation based on the concrete type a generic type is instantiated with.

Do you mean reasoning about a function in the sense of just understanding what a functions does (or can do), i.e. in the view of the practical programmer, or reasoning about the function in a typed theoretical system (e.g. typed lambda calculus or maybe even more exotic)? Or maybe a bit of both? There is certainly a concern from the theoretical viewpoint but how important is that for a practical programming language?

For example, I believe C++ template programming also breaks "parametricity" by supporting template specialisation. While there are many mundane issues with C++ templates, breaking parametricity is not a very big deal in practice. In contrast, it enables optimisations that are not otherwise possible (for templates). Consider for example std::vector<bool>: implementations can be made that actually store a single bit per vector element (instead of how a bool normally is represented using an int or char). Maybe this is even required by the standard, I don't recall. My point is that in makes sense for C++ to allow this, I think.