Science <-> Religion Comparisons

[electroBeam]

found an interesting answer to a software question https://softwareengineering.stackexchange.com/questions/7217/frankly-do-you-prefer-cowboy-coding

Can you see the parallels between spiral dynamics and this post? How interesting? 

There are many, but my favourite are these:

- the quasi engineers are dogmatic about their coding paradigms, just like stage blue. It manifested due to seeing the limits of the previous stages (just like spiral dynamics)

- the last stage (duct tape programmers) look just like the cowboy programmers. Yet they are completely different. Just like how yogis look exactly like religious fundamentalist nutcases. And the reasons why this is so are the same! And the cowboy programmers are completely ignorant of this. 

 

Interesting how spiral dynamics incorporates mini spirals within specific domains of expertise (such as programming!)

[integral]

wow this is fun , started reading "Coders at work" as recommended by the post, seems these duck tape programmers really like functional programming lol...

 

Tier 1:

- Cowboy coders: red, get the job done at any cost, leaves the world in ruins when its done

- Architecture Astronauts: blue, needs structure, follows what has worked in the past

- Quiasi-engineers: orange, innovative within the box, scientific in its approach but cant see the systemic bigger picture, resulting in overly complex designing/tooling to make things work within the paradigm, incapable of addressing the root cause of the problem because they cant see it. 

Tier 2:

- Duct tape programmers: green, low yellow, sees the bigger picture, developed intuition, constantly learning. effective, plants seeds that will continue to grow long after his job is done. Still stuck in a paradigm, distills the essence of the paradigm, what works and what doesn't, No bull shit, only what is useful and effective is kept, but no real innovation is achieved that effects the industry. The wheel keeps spinning. They are the 10x developers.

- Integral developer: mid to high yellow, highly developed intuition, sees the root of the problem,  striving to make the best possible move, can effectively strategically navigate the chaos, Innovates at all levels. Takes into consideration all quadrants in its approach. Fixes the problem at the root. Shows the world a better way of doing things that no one is ready for. Takes 30+ years before there ideas are rediscovered. An example: Can programming be liberated from the von neumann style referenced in the book "coders at work".

Edited May 26, 2019 by integral

[electroBeam]

@integral ooooo what an interesting take on it!!!

Wow what a mind blowing article you posted! 

 

 

 

[integral]

@electroBeam is this sarcasm? lol

[electroBeam]

8 hours ago, integral said:

@electroBeam is this sarcasm? lol

Nope. I love functional programming. But there are many programmers out there who use it not because they see value in it but because it is cool and different. FP is misused and that was the comment I was making.

 

One of the greatest things about functional programming over imperative is its 'if it compiles, it works' element. Also the fact that it can be mathematically reasoned and analysed.

Generative and proof based testing is becoming more and more essential as the world heads to more and more complex software projects. As software evolves, more and more software becomes abstracted. This leads to higher and higher programming languages (away from the metal). But if programs are getting more and more complex, does that mean it takes more work to write it? My argument is no it doesn't. This is because the compiler is doing more and more work to resolve the complexities of the abstractions. BUT!!! And here is the problem: The compiler is capable of sorting out compile time errors, but not runtime errors. So while the complexity of compile time errors (and therefore workload) is being mitigated, the complexity of runtime errors are not! The solution? Functional Programming! Because functional programs can have their runtime errors fully resolved by resolving their compile time errors. How amazing!

You can really feel this problem in the imperative scene. I've seen some companies use over 1000 test cases for 1 project (albeit it was a big project). Whereas on the other hand, having 1000 test cases for a functional programming project is just silly, especially with quick check. Because of FPs mathematical properties, you can automate the runtime errors as much as you can the compile time errors.

In fact, for any project I do, even imperative ones, I always try to automate test cases. Automating tests cases in an OOP setting is one of the hardest and most challenging things there is you could do, but its necessary to produce code that really does work.

Edited May 27, 2019 by electroBeam

[integral]

@electroBeam Fully agree , with AI coming, it seems its going to take over development before the industry figures out these lessons. But cant complain, a hybrid language merged with AI sounds great.