| |||||||||||||
LFCS 2012: The future of GLIBCLFCS 2012: The future of GLIBCPosted Apr 20, 2012 8:44 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)In reply to: LFCS 2012: The future of GLIBC by pr1268 Parent article: LFCS 2012: The future of GLIBC
I think the crucial difference here is that the progenitors of PHP themselves had severe contempt for proper design and implementation. It seems that in many cases worse may be better, but I believe worst is always worst. "Worse is better" doesn't imply that success is equivalent to a race to the bottom; there's a threshold of optimality backed off from perfection where real progress reaches a peak and past that you fall off a nasty cliff. I don't believe the C library to be the best possible library beyond reproach. GLIBC inherits from the storied C / UNIX / POSIX legacy, and has to deal with all the fun that comes with that. Sure, we have some self-inflicted wounds here and there, but mostly our warts are enshrined in POSIX or a C standard. (For example, gets()) That legacy also comes with a lot of experience and respect for proper design and implementation. I don't see any radical rejection of proper software engineering practices or proper architecture happening. I think GLIBC will be just fine. I'm glad to see its development get a shakeup. It reminds me a bit of EGCS vs. GCC. PHP, on the other hand, seemed to reject respect for proper engineering from the get-go, if I read Rasmus' quotes properly. I think that's the fundamental distinction to pay attention to here.
(Log in to post comments)
|
|||||||||||||