[troad]

I've come to the view that the best flow is to build a system in a dynamic language, and then - once you've got the broad strokes figured out - begin gradually typing it, where appropriate.

You definitely need to have a decent grasp of architecture to make this work - strict FP is very helpful to prevent any early spaghettification - but you ultimately get the best of both worlds this way: rapid iteration for the early stages and type safety once you develop a feel for the system you're building.

I've been doing this in Elixir in the last few months and I've really been enjoying it.

[zelphirkalt]

Yep, I agree with this. This is what I usually try in Python. Granted, Python is a way worse vehicle for FP than Elixir is, but I try to keep my procedures as pure functions as far as possible with not too big sacrifices in readability and performance. Most of the time a functional solution can be found, even in Python.

And maybe I am a little bit delusional thinking this, but in my experience, when you think deeply and come up with strict FP solutions, and you know what you are doing, then a lot of type issues don't arise, or are obvious to avoid. The simple fact that one thing you initialize once doesn't change over the course of its lifetime, already avoids tons of mistakes. You simply don't get this "Oh, is at that point in time that member of object x already modified, to be value y?" shit.

[troad]

> Yep, I agree with this. This is what I usually try in Python. Granted, Python is a way worse vehicle for FP than Elixir is, but I try to keep my procedures as pure functions as far as possible with not too big sacrifices in readability and performance. Most of the time a functional solution can be found, even in Python.

That's really interesting. The last time I wrote any serious Python was back in the Python 2 era, so it's been a hot minute, but that Python certainly didn't feel very amenable to FP. Nice to hear that it's turned a corner. I'll keep an eye out for any use case where I could give FP-flavoured Python a spin.

> And maybe I am a little bit delusional thinking this, but in my experience, when you think deeply and come up with strict FP solutions, and you know what you are doing, then a lot of type issues don't arise, or are obvious to avoid. The simple fact that one thing you initialize once doesn't change over the course of its lifetime, already avoids tons of mistakes. You simply don't get this "Oh, is at that point in time that member of object x already modified, to be value y?" shit.

I very much agree with this, and I wish more FP evangelism focused on the many wonderful emergent properties of FP systems in production, instead of cutesy maths cleverness that turns off more people than it attracts (and those that it attracts were always going to be functional programmers to begin with).

[zelphirkalt]

To be clear, Python is still no good for FP, when comparing to other languages, including the aforementioned Elixir. Even though the Python ecosystem is huge, few people if any seem to spend any thought on functional data structures. And also you wouldn't be able to use them like in typical FP languages, because you don't get tail call optimization. You can only try your best in Python.

[troad]

Gotchya.