Its the usual case of not being able to have your cake and eat it too.
If you want top performance you have to manage memory yourself plus the abilitiy to access thousands of C libraries is not such a bad excuse for a compromise. The FFI is not a problem is a solution to many problems and people using it its not as if Smalltalk offers them any alternative choice.��
Not to forget that Slang itself relies heavily on C, which is only the core of the VM and the very core of the implementation.��
Understanding how to work with pointers in C is pretty much understanding how to works with Objects in Smalltalk. Both are nuclear weapons that those two languages are build around. If ones does not understand their usage he will shoot his foot in the end.��
The important thing to remember is that C's goal is not the same as of Smalltalk. Its not there to hold your hand and make coding easy for you. C is there to offer low level access combined with top performance. It may have started as a general purpose language decades ago when coding in Assembly was still a pleasant experience. Nowdays C has completely replaced Assembly as the top performance language for low level coding.��
C may appear as a problematic language to a Smalltalker but only because he sees it from the Smalltalk point of view. The harsh reality of the world is that as much as one may want to shoehorn it , not everything can be elegantly mapped to a object. Smalltalk may be OO to the bone , but the world we live in, cannot afford such simple structures to accomodate of varied immense complexity.
On the subject of pointers, the general rule of thumb is to keep things as simple as possible and avoide trying to do weird "magic" with them. There is a ton of things that C does under the hood to generate highly optimised machine code that can fry the brain , as the usual case with low level coding,�� so keeping it simple is the way to go.��
Oh and dont try to shoehorn the Live coding enviroment in debugging C code, as much as one may want to brag of Smalltalk's elegant debugger, C development tools are light years ahead in dealing with C problems.��
May advice to people is that if you do it via FFI first, you do it wrong.
Do it always first with C with a powerful C IDE like Visual Studio, make sure your code works there and then use the UFFI. Will make life thousand times easier. I learned that the hard way when I was playing around with Pharo and shared memory.��
So yes having a FFI that does not help you avoid coding in C first, is a big plus, not a minus. Sometimes it makes sense to live outside the image, this is an excellent case to prove why that is a great idea. .����