Gilad Bracha writes...
So far, I have no firm conclusions about how to best address the problems monkey patching is trying to solve. I don’t deny that it is expedient and tempting. Much of the appeal of dynamic languages is of course the freedom to do such things...Gilad captures the essence of truly dynamic languages: freedom. Get out my way with your type theories. I am squarely in this camp for the time being.Regardless, given my flattering portrayals of primate practices, you may deduce that my main comment on monkey patching is “just say no”. The problems it induces far outweigh its benefits. If you feel tempted, think hard about design alternatives. One can do better.
I've not run into all the problems Gilad apparently attributes to dynamic languages. (And I assert your language is *not* dynamic if it does not allow these kinds of extensions.) I will welcome Gilad's solution as long as it preserves all the value. Generally though we should favor fewer language mechanisms, embrace those simple mechanism that work, and rely on good programming practices.
His Newspeak could be the rare exception, but I've not seen many whole language advances that really improve things as much as programmers can improve their own practices. I wonder if Gilad is expecting his Newspeak to appeal to the developers he refers to as "baboons"? It seems that distrust of developers is alive and well.
4 comments:
Newspeak is built on top of smalltalk (currently squeak I think) - so it will certainly be a fuly dynamic language.
The one does not necessarily imply the other. I have used the C-language (Zeta C) running on a Lisp Machine. Symbolics had Ada, Fortran, Pascal, and maybe other static languages compile to their Lisp Machine.
I'm reading this very differently than. I see that he thinks monkey patching is dangerous, but he thinks the alternative is really bad too. It sounds to me like he is trying to find a way to allow for the flexibility in a more controlled manner.
BTW, this is why I left Ruby and went back to Python. You can do it in both, but the Python community tends to find an alternative and only uses it as a stop gap / last resort rather than a library design technique.
The issue with monkey patching Bracha appears to be concerned with is the injection of patch methods into the namespace of the patched object, which then conflicts with other attempts to patch the object. At least two 'C family' languages, objective C and C#, solve this by not allowing the extension methods to be visible to other processes (objective C) or namespaces (C#). The issue isn't one of dynamic or static typing, but of name binding.
Post a Comment