Functional Programming is currently experiencing a battle between those who see formalism as essential to…

Functional Programming is currently experiencing a battle between those who see formalism as essential to comprehension versus newly converted developers who just want to use the stuff and are totally happy with simplistic metaphors.

The difference I guess is that the former group will continue to innovate and create new insights while the latter group will slowly absorb and put them into practice in their daily work (after a delay, sometimes decades after these insights and innovations were made).

2 thoughts on “Functional Programming is currently experiencing a battle between those who see formalism as essential to…

  1. Formal methods and quantum computing. Both are hard to understand, but that is where the future is.

    And you know, there is a debate as to whether software engineers should actually be called “engineers,” since we don’t have to certify our knowledge with the state. You could say it’s because software engineering is too easy: if the computer crashes, people usually don’t die as a result.

    But now that people finally realize that security is so important, maybe software engineering should be a state-certified thing. Maybe we’ve been getting a free ride all this time, maybe we should be forced to learn the harder things, like formal methods, in order to have the right to call ourselves “engineers.”

    Like

  2. Ramin Honary in my experience “engineers” is the right name because most engineers are users of tools and methods rather than inventors of those tools and methods. Actually the bar is even lower than that. Most wouldn’t even know an algorithm if it bit them on the arse.

    In other words, you can raise the academic requirements of the job but the requirements of the industry will always in the direction of lower skill levels rather than higher ones. I’m inclined to not fight that. Better to tell people who don’t think for themselves what to do i.e. Get them to adopt these ideas as industry “best practices” and standards rather than requiring of them a deeper understanding.

    This worked fine for OOP. Gradually the more advanced approaches will filter down (to some) as they become more familiar.

    Like

Leave a reply to Ramin Honary Cancel reply