[shrimp_emoji]

> doing anything else is fighting against the environment

Video game programming, where performance really matters, is a great way to see the cost of forcing the hardware to deal with human abstractions (mainly OOP). Rules like "never have a Boolean in a struct" or "an array with linear access can be faster than a tree with log access" wake you up to the reality of the hardware. :p

In academia, and the especially academic, utopian realm of functional programming, you're trained to live in dreamland.

If you can afford it, though, hey, it's a nice place to be.

[sodapopcan]

> In academia, and the especially academic, utopian realm of functional programming, you're trained to live in dreamland.

OO outside of contexts where every little bit of performance matters suffers in exactly the exact same way.

> If you can afford it, though, hey, it's a nice place to be.

No arguments there! A huge majority of applications can afford to be written this way, even ones where performance is a concern (WhatApp, for example).

[jjav]

> A huge majority of applications can afford to be written this way, even ones where performance is a concern

This is sometimes true for any one given app but it's not a good overall outcome.

It is why we have today multi-GHz CPUs with lots of cores and dozens of GB of RAM and yet... most actions feel less responsive today than in 1995 with a 120MHz CPU, 1 core and 1MB.

[sodapopcan]

My comment was in response to the need to squeeze out every last bit of performance you possibly can. You're talking about ignoring performance altogether which is not what I'm talking about.

[garethrowlands]

Then again, abstractions can be helpful too, including in game programming. Epic's heavily invested, for example. Or in databases, relational algebra often beats out an array with linear access. I agree that OOP-in-the-small lacks mechanical sympathy though. That's one reason for entity-component-model, though another, I'd argue, is that it provides abstractions that are easier to reason about.

[pjmlp]

On Epic's case it helps that Tim Sweany started his game company doing games in VB, and always cared for a good developer experience, that is why Unreal Engine always favoured good abstractions, has a C++ GC, Blueprints and now Verse.

He was never a kind of "lets keep doing C in games" style of developer.

Thankfully, without the likes of Unreal, Unity and similar efforts, we would still be doing like it always was done here, kind of mentality.

[wredue]

Andrew Kelley has a pretty good talk on gaining performance in the zig compiler.

In many cases performing math again is faster than memoization.

General gist is to try to cram as much in to the cache lines as possible, sometimes even at the “cost” of calculating values again.

[pjmlp]

Jax and Daxter did pretty well for a game written in Common Lisp.

And apparently Epic belives enough on this to create Verse, and to quote Tim Sweany point of view on "The Next Mainstream Programming Languages",

http://lambda-the-ultimate.org/node/1277