2012/6/3 Igor Stasenko <[email protected]>: > On 2 June 2012 18:42, Nicolas Cellier > <[email protected]> wrote: > ... >> >> Ouch, Igor, you gonna give us a headache. >> That's exatly the kind of niceties that makes FFI impracticle without >> a pre-processor, remember our discussion? >> > > That kind of niceties is a poor man's meta programming. > I don't see it as an argument against FFI. For me it is a clear > argument against system design. > > Because look.. most of the times you don't care what happens under the hood of > your sport car.. until it stops working, or no longer meets your demands. > From position of consumer , it is clear what you do next - you go to > market and buy a new one, > or give it to engineers who can fix it. > So, either there is someone who can produce better cars (engineers), > or someone who can fix > your car (engineers). But if there nobody left, and only consumers > around, then you are in trouble. > > And FFI actually points to that trouble: you cannot communicate with > system without having > a highly sophisticated compiler and preprocessor and also without > knowledge about which bells you should ring and what whistles you > should whistle.. this is road to nowhere. > > This is clearly not FFI's fault. It is fault of system design. > For example, look at config.h file, which produced by autoconfig > utility.. can you tell me, what all those flags controlling? Ok, name > me the purpose of half of them.. Can you? > And then tell me, how you can write a "highly portable" C software and > guarantee that all those bells and whistles are correctly arranged? >
Sure, I don't blame FFI for being mud, just for exposing such mud. As I told you, I doubt I'd like it to be mirrored in image. The mud is everywhere, and there ain't much we can do. So how are we supposed to fix this? Throw away linux/FreeBSD/MacOS/WinXX and start an OS from scratch? Fight with more mud crystallised in hardware with SqueakNOS? This purpose of FFI is to open the gates to the external world, not to increase our autism. There is a solution in such cases: we can wrap mud in a nice packet by writing an interface library that uses highly sophisticated compiler and preprocessor, advanced knowledge of C code hackers, and community support for building various distributions (youpi with autoconf Cmake and the like)... It's a bit simpler than writing a plugin or VM code because no knowledge of Smalltalk/VMMaker/slang is required. But, not very much different at the end. Nicolas > From position of an engineer it is wrong to be on the side of > consumers (i don't care, it is something under the hood of my car, > which makes it run). > And for sure, nobody cares about insignificant little fly such as Cog > VM, except from few of us. > So, you have to go and open a hood of a car and remove a rotten cats & > rats from there, > this is how you can move to better future. Otherwise at some point, > cars will stop working, > planes will stop flying, computers will stop working, because nobody > will be left who would > understand how to make or fix them. > > So, this is a right question, posed by Stephane: how we can make sure > that we will be able to > improve system in future, once its creators are gone, and nobody can > understand it anymore? > Only by simplifying and cleaning all layers of a system and without > relying on good Santa, which will come one day and clean this mess for > us. > > -- > Best regards, > Igor Stasenko. > Depends on
