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.

You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.

> incredibly easy compared to getting them to edit some vim/emacs config

Yet, extending just about any functionality of Emacs for an experienced user is far simpler than in anything else - you can write some expressions in a scratch buffer and change the behavior of any command - built-in or third-party. Not only wouldn't you even have to restart anything - you wouldn't even need to save that code on the file system.

There's a strong correlation between perceived difficulty at the beginning and notable simplicity at later stages. Things that are seemingly harder to grok often open up avenues for clarity later. Conversely, things that seem easy to get into, later often become full of bottlenecks and complexity.

Imagine attempting to replace all the knobs, controls, buttons and switches in an Airbus A380 cockpit with a single touch-based display à la Tesla and claim it's now easier to train new pilots, but you've just made them dependent on a system they don't deeply understand, you've traded 6 months of training for a lifetime of brittle expertise.

I am forever indebted to my younger self for investing some time in understanding the grand ideas behind Vim and Emacs, and never, even once, have I regretted my choices. Rather the opposite - I regret wasting a big chunk of my life chasing popular trends aimed at "intuitive use", "easy start" and "it just works™". I would have never developed the true "hacker's mindset" without them.

Undeniably, there's an immense pedagogical value in tools that make it easy for beginners, but there's also a mental trap there. It's ingrained into human nature - the brain simply doesn't like the grit; it naturally gravitates toward comfort and minimal effort - it just wants to remain lazy. Yet there's a compounding effect of initial investment that pays off later. Sadly, we keep trying to find ways to dumb things down.

I think it depends on the music. Most people will have a greatly improved experience when listening to opera if they have access to (translated) lyrics. Even if you know the language of an opera, it can be extremely difficult for a lot of people to understand the lyrics due to all the ornamentation.

What percentage of streaming income does opera, as a genre, represent such that it could even factor into this business decision?

Why not both? As the GP mentioned, lyrics are also invaluable for people besides training for AI.

I think the perceived lack-of-value for them is related to how easy it is to write lyrics down, compared to any other aspect of the music. Anyone can do it within the time of the song, usually first try. Any other aspect of the song cant't just be written down from ear (yes, including the sheet music, which isn't nearly expressive enough to reproduce a performance*).

*There are some funny "play from sheet music without knowing the song" type videos out there, with funny results. YouTube/google search is no longe usable, so I can't find any.