> The root cause of bad software has less to do with specific engineering choices, and more to do with how development projects are managed.
...While I do agree that "project-management" is important, I think the tools we are using today are really underpowered to deal with complexity/human-error - Which is the bigger problem IMO.
I'm coming at this from the Elm-camp, and my first impression (and largely why I think languages like Elm is promising) is how languages that are implemented as supersets of other languages have the potential to be as bad as their subsets.
The example that I was given was C++ and C, but I think TypeScript with it's gradual-typing approach is forced to remain potentially as bad as JavaScript itself - that is, if you're feeling weak and want to "get shit done", you can bypass all the goodness that TypeScript undeniably offers you.
For a language like Elm, the type-system is invariably gonna have your back - a value-proposition I think means a lot more in practice than some self-proclaimed pragmatists realize :)
I don't think annonymous functions have anything special to do with FP or OO for that matter. Maybe someone can fill in on this?
In my mind, functional programming is about programming with mathematical functions - Purity - No arbitrary effects being thrown around - Input to output... Ba-Da-Boom-Ba-Da-Bing.
I find this much more valuable as a restriction from the runtime than as a guideline that can be ignored whenever deemed convenient.
That being said, I wouldn't have a job if I couldn't compromise on this :(
Is there any way to enforce some purity in F#? Does the type-system annotate effectfulness?
I feel like commenting on the callbacks and variable-bound-contexts, and saying something about the glorious wonder of modern JavaScripts... better not, tho :)
These use-cases you're implying seem to be the real problem.