Side comments...
Some code just has to be written in C, otherwise you cannot rely on the
behavior being correct and ultimately that's a major show stopper for
anything you might want to call "production" code. Anything having to
do with calling operating system libraries is a typical example of this
phenomenon. So, in those cases, translating Smalltalk to C (or
interfacing to OS libraries with FFI interfaces) only gives you huge
maintenance headaches in the long run. The resulting distractions due
to bug reports will obliterate any engineering team's performance, and
it's a race that cannot be won as framed. POSIX is there for a reason,
let the C compiler do the job it's been doing for 40+ years.
But suppose one wants to write C code with Smalltalk syntax anyway.
Nevertheless, C99 and newer still apply and one must be aware of the
subject matter. The danger is that Smalltalk is so much more user
friendly than C, that once one starts writing C in Smalltalk one will
never look at the automatically generated C. But is the mechanically
generated C code valid? Because if not, then compiling such source code
can be no better than "garbage in, garbage out", and then you cannot
have production quality. Similar arguments apply to FFI interfaces.
Please excuse my ignorance, but I'd like to assume someone's looking
into this?
What seems to follow is that the architecture of the system should try
to minimize the dependencies on external libraries, precisely because
the dependencies cause exposure to foreign rules and regulations that
slow one down. Creating dependencies in a reasonable manner should be
straightforward _for system users_, though. Letting externals create
reliable dependencies on one's system should also be facilitated to
promote healthy modes of interaction with the community at large.
I feel one of our current challenges is to wholeheartedly admit there is
no royal road to inventing our future, then act accordingly.
Andres.
