I was in a meeting with a senior software engineer, who makes a shit ton more than me. While sharing my screen he saw flame graph I had for one program I was working on. They asked "what is that?", I was taken back, and said it's for looking at which functions are taking more time. Then I was asked "where did you find it?" I was shell shocked, didn't know how to answer that. Similar things have happened before where I taught them certain things, and they go "great find", like dude, I didn't find it just now. That's basic knowledge if you work with database.

I am not even a developer hire, I'm self learned, and because the company doesn't have many developers they gave me some of the tasks and I'm doing it because it's more fun than my job responsibilities, and when I don't have enough tasks.

Pay me to do it and I'll gladly do it. Most companies, however, don't really care much about whether the customers take an extra 100 milliseconds for every request or not. And when it's promotion time, you're often judged by how many tasks you get done, not how fast your code is.

All programming is a trade-off between what's easy for the developer and what's fast for the machine.

Sure, you could theoretically write everything in Assembly and it'd be blazingly fast; but unless you're a particularly elite developer, that process would take forever for any program more complicated than a calculator, the result would be super buggy, and those bugs would be very hard to fix.

On the other end of the spectrum, you might imagine a natural language machine learning compiler which translated directly from human prose to binary. It would be dead simple to "program" anything in; but such an application would probably be unbelievably slow, and again, have a staggering number of difficult-to-fix bugs.

Somewhere in the middle are modern programming languages that abstract away all of the stuff that's necessary but hard for humans to wrap their minds around (memory management, API interaction, network stack, etc) and let the human write clear and unambitious code to handle all of the business logic and displaying it to the user. The result won't run as blisteringly fast as writing directly in Assembly, and it won't be as quick to market as Vibes-to-ASM, but the application will be developed in a reasonable amount of time and be reasonably easy to maintain.

Why not just use the faster language?

Because the other language is more developer-friendly or faster to write/read even if slower to execute. Some code doesn't need to be fast because it is always waiting on other things anyway.

Some languages effectively prevent whole classes of runtime failures / bad code. But, they do that by doing more which takes longer, at compile-time, run time, or both.

Some programs can't avoid graph-structured data dependencies. In that case, the simplest solution is a garbage collector, and one built into the runtime is capable of being more efficient (and less buggy) than one written for a specific program.

Anyway, there are many factors that determine which language is "best", and not all of them are objective. That's why we don't just use the fastest language. (Currently, I do all my coding in either Idris or Purescript, but I'm also unemployed and just programing for myself, for now.)

IMHO it's easier to quickly iterate with Python than with C++. If you aren't even sure what you want and you're just writing stuff, then Python is great. Is "4" true? Ofc it is.

Profiling complex systems can be quite difficult. That said, I believe in the adage "Profile twice, optimize once.", adapted from the old carpenters adage of "Measure twice, cut once."

Slowness is rarely essential, but I can be far away from where you expect it.

God, this again.

Web development and using browser renderers for GUIs is one of my most hated aspects of modern software. 🤢