[keithnz]

Functional Programming and Category Theroy are great, there's a strong level of robustness in the whole approach to programming.

The author slams imperative programming, it isn't backboned on a robust compositional system, as is often done by FPers

BUT :)

there's lots of good programs in both styles....to me, this implies that there are more important things that matter to programming, the design to achieve a purpose. It's nice to express your designs in a robust system ( and be influenced by it), but what matters most is the design choices you make. When I look at well programmed things it's always the design choices that impress me.

[m_mueller]

Coming from HPC, I think imperative programming will stay as long as we don't have an AGI that does the actual programming for us, as it's the model with the highest possible abatraction that still gives you the whole truth about the underlying memory operations (and thus allows you to optimize for it without having your hands tied behind your back and just trusting the compiler gods). Not saying that this is how one should usually program in a context where performance is not the highest goal, but there's always going to be these usecases.

[jonahx]

Agreed. That said, the problem is that imperative programming is still used widely in contexts (eg, 95% of web programming) where performance is not an issue and high-level abstractions such as those used in FP are more appropriate. This is almost entirely due, imo, to the paradigm's inertia and to bad education.

[thomastjeffery]

The wonderful thing is that we can mix the two.

One great method is to write your program using a nice functional language (Haskell, CL/racket/scheme, etc.), and where you want optimizations, replace functions with lower level imperative language implementations (C/C++, rust, etc.) and FFI.