std::array can sometimes give you the best of both worlds for stack allocation in that you statically constrain the stack allocation size (no alloca) while guaranteeing that your buffers are large enough for your data. You can also do a lot of powerful things with constexpr that are just not possible with arrays. It is very convenient for maintaining static mappings from enums to some other values.

That is not what they should do according to microeconomics because luxury goods are Veblen goods. Decreasing price would lower demand, at least until they lowered it enough that it was no longer a Veblen good.

Basic microeconomics is just that: basic and thus an oversimplification.

This already happens a lot for used clothes with the thrift store->poor country->landfill pipeline. That third step will likely be a lot less rare with new clothes.

A vector of boxes is beneficial if you need to move objects around. If each T is 1000B or something, you really don’t want to copy or even do true moves in memory.

Hell, even if you’re not moving things around explicitly, don’t forget that vectors resize themselves. If you use Box, then these resizes will be less painful with large objects.

Of course, the language lets you decide. I think this anti feature is actually a feature.

As long as you have a FedEx or library nearby, you can print things there

I enjoy both and have ended up using AI a lot differently than vibe coders. I rarely use it for generating implementations, but I use it extensively for helping me understand docs/apis and more importantly, for debugging. AI saves me so much time trying to figure out why things aren’t working and in code review.

I deliberately avoid full vibe coding since I think doing so will rust my skills as a programmer. It also really doesn’t save much time in my experience. Once I have a design in mind, implementation is not the hard part.

I think the examples others have highlighted show the problem with just making it a library. They’re all lacking a lot of features from Prolog, particularly in terms of optimization. Just use Prolog if you need its features and invoke SWI-Prolog like you’d call any other language’s interpreter.

Agree. The optimization caveat also applies to OOP, another example someone threw in above.

Sure you can implement OOP as a library in pretty much any language, but you’ll probably sacrifice ergonomics, performance and/or safety I guess.

I might need to try it out. However, I haven't really found a use case yet where the speed of Python has been a major factor in my day job. It's usually fast enough and is a lot easier to optimize than many languages.

I actually sped up a script the other day that had been written in bash by 200x by moving it over to Python and rewriting the regexes so they could run on whole files all at once instead of line by line. Performance problems are most often from poorly written code in my experience, not a slow language.

And it needs to be said that you generally cannot tell if a vulnerability is critical for a given application except by evaluating the vulnerability in the context of said application. One that I've seen is some critical DoS vulnerability due to a poorly crafted regex. That sort of vulnerability is only relevant if you are passing untrusted input to that regex.

That sounds like mania which is even more likely considering that early depression is often actually bipolar.