Hacker News Reader

Comment by ajuc | Hacker News Reader

Yes. And it's one of the most important reasons OOP is so bad at multithreading.

You want "pretty" OOP? Tell Don't Ask.

You want performance and reliable multithreading? Command-Query Separation. Which is basically the same as functional programming :) Make all the functions pure except for a few clearly marked ones with side effects.

It's especially visible in gamedev. After a decade of trying to make OOP work with multithreading people moved on to Entity Component Systems (which is basically imperative programming with some relational and functional aspects).

It's also why functional programming is getting more popular - because it is pull by default. It's also why almost all graphical shaders are functional even if they look like C :) Many inputs one output and no side effects :)

View on HN

> graphical shaders are functional even if they look like C :) Many inputs one output and no side effects :)

That's not functional programming, it's just pure functions. Shaders make use of sequential execution of statements, and they don't support recursion.

you are splitting hair on definitions.

It is the pure function nature of functional programming that makes it easy for concurrent and parallel tasks. Recursion is neither here nor there

It's not hair-splitting. As I understand it, functional shader languages are an active area of research. Mainstream shader languages such as HLSL are most certainly not functional.

Languages are functional if they support higher order functions, recursion, closures, etc.

Code is functional if it separates side-effects to small, clearly marked parts of the codebase.

Man I love entity component systems. They're elegant, yet super hardware friendly. Extremely simple and easy to understand.

I have a background in Databases and it's always interesting how ECS face some of the same problems the DB field faced, they just haven't realised it yet. They require super fast joins to figure out which components to feed to the systems for example.

I'd predict massive cool strides in the DB and ECS/Gamedev/Simulation world, once the two realise how much they can learn from one another.

My dream is marry relation + array + functional + bit of imperative for a programming language (building slowly at https://github.com/Tablam/TablaM). But the ECS is one paradigm that must fit here but don't see how actually apply in more "normal" scenarios like erp/ecommerce programming. Do you have any hint?

My hunch would be to have a RDF-like (not RDF cause that sucks, but flexible self describing triples) graph database, that is append only (similar to a persistent datastructure). With systems subscribing to query streams and appending new facts. So like an event sourcing / rdf / ecs hybrid.

Uuid are Entities, for easy distribution. Components are just entity attribute subsets in the DB. Systems are external components subscribing to queries.

This wouldn't have all the nice memory layout properties of ecs, but the thing is that "normal" doesn't need fast. "normal" needs correct, and provenance, and accountability.

If you wanted subparts in such an architecture that are high speed you'd make them regular ecs components, and have them log into the append only store at intervals/checkpoints/whatever.

Reply on news.ycombinator.com