I think you should cover what you mean by "memory safety" in more detail because I think it is actually very important and not just a matter of personal preference. To do so, you could cover what happens when you call factorial(UINT_MAX) and how that affects the call stack in the implementation of some languages.
I am not a functional programmer but for many imperative languages (like JavaScript, C++, C#, Java), the language is typically implemented using a call stack. The call stack is conceptually a per-thread, last-in/first-out data structure that keeps track of where to return to when executing nested functions. If a thread's call stack gets too deep (where the definition of too deep depends on the language, operating system, hardware, etc.), a stack overflow condition can be raised which can crash the executing program. Generally if the depth of recursion is not restricted in some way so that it can guarantee that a stack overflow won't happen, then an iterative approach should be applied.
In my opinion I would also weary of issuing general guidance that relies on tail-recursion compiler optimisations because not all languages guarantee it (e.g. C# may use tail-recursion optimisations but it is my understanding that there is no way of guaranteeing it at compile time).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the article.
I think you should cover what you mean by "memory safety" in more detail because I think it is actually very important and not just a matter of personal preference. To do so, you could cover what happens when you call factorial(UINT_MAX) and how that affects the call stack in the implementation of some languages.
I am not a functional programmer but for many imperative languages (like JavaScript, C++, C#, Java), the language is typically implemented using a call stack. The call stack is conceptually a per-thread, last-in/first-out data structure that keeps track of where to return to when executing nested functions. If a thread's call stack gets too deep (where the definition of too deep depends on the language, operating system, hardware, etc.), a stack overflow condition can be raised which can crash the executing program. Generally if the depth of recursion is not restricted in some way so that it can guarantee that a stack overflow won't happen, then an iterative approach should be applied.
In my opinion I would also weary of issuing general guidance that relies on tail-recursion compiler optimisations because not all languages guarantee it (e.g. C# may use tail-recursion optimisations but it is my understanding that there is no way of guaranteeing it at compile time).