"one of the reasons that Smalltalk historically has been view as insular, living in its own world avoid using non-Smalltalk libraries - because the lose of live coding here is a big impact."
I would not say that Smalltalk is viewed as insular. I would say that Smallalk is not viewed at all period. Pharo wise the people who introduced to Pharo have been impressed by it. The same way most Pharoers prefer pharo libraries to c libraries via UFFI , applies to python coders as well. You think a python coder is eager to leave the comforts of his language, think again. In both communities its user with either C experience or motivated to learn C for personal reasons that use the FFIs or other means to import C code. Is it an accident that 99% of C wrapped code libraries for Python are existing C projects ? Some existing for decades and predating Python. A pure Python developers will be as unlikely to use the FFI as a Pharo developer, and by developers I mean users not the people who actually develop Pharo. So no there is nothing wrong with Smalltalk and Smallalk works with C just fine. Python's C API gained quickly reputation among the C people of being easy to us so Python became the go to language for scripting C. This is also why Python offered embeding, because back then Python was slooowwww. This led Guido to claim that Python may be a great choice for scripting C project but choice for replacing high performance code. He did not even intended the language to target anything else than scriptin. Nonetheless that did not stop the community from pop up like mushrooms high performance libraries to that extend that nowdays Python is regarded as the second best choice for high performance computing after C/C++ which if you think about it sounds kinda insane but non the less wrapped optimised C python libraries can easily outperform non optimised C/C++ code. An example being the emarashing truth that Python strings are faster than C++ strings which forces C++ coders to use an external library that optimised them called Boost. So the real irony is that back then embeding Python was recommended, nowdays embdeding Python is frown upon. Instead now its recommended to brake your C project to a library wrapped for Python and import it to Python. Its fascinating to see something that started so humble become so ambitious but that is true power of the community and this is also the true power of Pharo. You can let this misconceptions get in the way and think small like "Python/Pharo cannot do this, or is hard to do" or you can shut up (something I find hard to do) and just do it. As I said , we use only 0.0000001% of the potential of any language out there.
