[toastal]

Here's a real life tangential example: I'm learning Thai. When I first started it was useful to show the Latin alphabet to get a grasp but it's often difficult or inaccurate to try to express that language without the system designed to express it. For instance, many romanizations lack a tone marker for tonal language, or don't show vowel length when it matters. Or for laughable example of พร, meaning 'blessing' but also a common woman's name, being traditionally romanized to 'porn' with its silent r when 'pawn' is a more neutral pronunciation for all English dialects (or /pʰɔːn/). Also, not being able to read or write the language, you will have a difficult time effectively engaging with the community and understanding the world around you.

The point is, functional languages are designed to express these concepts with much, much less cruft with extra features like currying, immutability-by-default, and type classes. Yes, use your current language to get oriented, but if you're going to really learn it, pick up a proper syntax to express it.

[saghm]

Sure, but to extend your metaphor, using Haskell to teach non-Haskell programmers about monads is like using Thai to teach English speakers the history of Thailand; the language might be better suited for the topic, but the people you're teaching don't know it, and learning it is orthogonal to the actual thing you're trying to teach them.

[toastal]

That's why I said have both with the emphasis on the one that better expresses it so people know what you're aiming for. I've written FP blog posts in the past with Javascript to accompany just in case it wasn't clear because of syntax. But if you'd just looked at the Javascript, your takeaway will probably be similar to many FP-in-JS articles of 'why so much ceremony?' The 'other' language is merely a bridge. And if you can only communicate from the bridge language's perspective, you won't be able to grasp intermediate topics.