#19803 Me lo dices en serio? yo hace tiempo que soy data oriented. Tio si llevo ya 1 a;o solo poniendo cosas de data oriented, todo lo que pongo de jon blow y la caida del software es data oriented por ejemplo. Si pase de OOP -> FP -> rust/go es por ser data oriented. si hago hexagonal/behavior driven y no fp es por ser data oriented. etc etc.
Tambien en el pasado cuando me he cagado en el OOP por hacer objetos y modelos abstractos INCORRECTOS el core es una cagada monumental, la FP se acerca mas a un modelo de abstraccion correcto pero la PROGRAMACION y la COMPUTACION eran, son y sera siempre data oriented. Aunque la Fp es un modelo de abtraccion muy correcto. Desde el punto de vista computacional de lo que es una CPU y como funciona internamente un PC, que por este hilo la mayoria deFPeros no lo saben ni lo entienden.
Lo interesante de esa regla N5 es que de ahi sale gente como Rich Hikey con su Clojure por ejemplo. Y del resto de reglas salen mucha gente, metodologias, tecnologias etc.
El opportunistic programming de hecho, que es el termino que alguna gente usa para referise al data oriented + hexagonal en esta decada, lo he posteado por el hilo con anterioridad. Y este esta relazionado con las ideas de unix philosphy que postee ayer en el blog. Puedes leer las reglas en el libro the art of unix programming o en mi blog. te dejo los titulos:
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for “one true way”.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
Lee todo esto y veras que es todo lo que los vende humos aplican, o ciertos gurus tecnologicos defienden en sus lenguajes, o ciertas metodologias de trabajo priorizan en su dia a dia. Incluso cosas como SRE o devops tienen sus raices en estas "reglas".
con esto no digo que ese libro sea el original que creo todas estas ideas, solo resalto que todas estas ideas estaban ya presentes en la industria en esa epoca y en esta secion del libro estan magistralmente explicadas. Es muy divertido ver los paralelismos.
Durante el paso de los a;os el pajeet no aprende del pasado, alguien viene y le vende el pasado a precio de oro.
Como paso en el arte, te robaron la belleza y te lo vendieron como lujo. igual que se ha normalizado ir al ikea porque no puedes pagarte un mueble de primera calidad, se ha normalizado el software BASURA. Puedes estudiar la historia del arte y sacar los paralelismos igual con esta industria de IT. Es lo que tiene la masificacion y que cualquier FPero se crea programador, aparte de picar mierda se cree con derecho a opinar... y asi nos va.
