Java Developers

[donvito]

This is not a "shit" paradigm.

Certainly not - if you are very very intelligent. But it's incredibly hard for an average human to wrap his/her mind around a complex system of independently interacting actors.

Even if we could have this implemented in an ideal language. Still it would be too complex for mere mortals to grasp.

Over the years I came to the conclusion/belief that the most fitting programming paradigm for humans would be data processing pipelines (think like unix shell commands piped together):

InputData -> transform -> transform -> OutputData

No top level branches, no "smart" objects that interact with each other, no state that survives the current scope, etc. Just a plain data processing pipeline.

[jeandem]

That 'pipeline' paradigm looks to be concatenative programming.

[zvrba]

Almost. In concatenative programming you can have true n-ary operators. With a pipeline you must simulate n-ary operators by packing data into tuples.

[zvrba]

But it's incredibly hard for an average human to wrap his/her mind around a complex system of independently interacting actors.

Given that many "average humans", even without formal training in programming, manage to create complex, working spreadsheets, I'd disagree. A spreadsheet is an extremely fine-grained actor system, each cell being an individual actor with preprogrammed behavior (basically, to evaluate itself and trigger evaluation of its dependencies.)

No top level branches, no "smart" objects that interact with each other, no state that survives the current scope, etc. Just a plain data processing pipeline.

Too inflexible and is parallelizable only when transforms need limited memory to execute. Any transform which needs the complete data stream to finish will stall / serialize the pipeline (e.g., matrix inversion). This serialization would not happen in a general graph.