Re: Fwd: What's up with Quercus?

On May 29, 2011, at 2:24 AM, Stas Malyshev wrote: >> - I immediately had to write an extension to give me access to >> several missing APIs (clock_gettime() and a number of ncurses >> functions not implemented in the ncurses extension). > So the problem with PHP is that it doesn't include support for any > possible API out of the box. While all other languages out there of > course do ;) More a question of I wish these existed: https://wiki.php.net/rfc/php_native_interface https://wiki.php.net/rfc/remove_zend_api >> types not in the original API was just a bonus.) - In general, I have >> to tiptoe all over everything to avoid getting useless >> notices/warnings for expected error conditions (such as SIGPIPE on > This is indeed a serious complaint, PHP tends to be over-verbose and errors are expensive. So > far there's no BC-compliant way to fix it has been found. I know, I tried at least 3 times :) > We need ideas there. Offhand I'd say there's no BC-compliant way at all short of providing a second set of APIs alongside the old ones. Which, given the naming conventions problem, might not be the worst idea, but would definitely be a nightmare in terms of consistency. >> - No threading support. > Threading in PHP wouldn't work. At least the one like they have in Java. Unless you want > to mess with thread synchronization, deadlock resolution and other stuff, which 99.9999% of PHP > users don't. That's fair. >> No preprocessor. define() makes up for only some of it, closures make >> up for some more, but still not enough. There are no mature > Here it may be interesting to note so does pretty much any other language except for C. True, and I've felt the lack in such languages as well. On the other hand, PHP is a bit more C-like then many; I don't feel the need in, for example, Lua. >> And yes, it does mean an engine rewrite. > That would be too easy. It also means throwing out most of the existing code and rewriting > everything that was done in last 10+ years in PHP. Then the question would be - why do it with PHP? > If you designing a language > from scratch anyway, there are so many opportunities to explore... Don't think I'm not tempted to design an alternative language. If I had the time and understood LLVM better, I probably would :). I don't really expect PHP to be rewritten, but if enough distaste is expressed with the current state of affairs, I imagine at least some things might change. On May 29, 2011, at 2:28 AM, Pascal COURTOIS wrote: > why not using a language designed for your needs ? The balance between rapid development, learning curve, and usability. One line in Python or PHP or even C# can equate to thousands in C. Python or Java might be a better match for what I'm doing, but then there's the question of putting in the time to become fluent with them and their libraries, and there is a time constraint. PHP has all of these issues, but 1) I know the language and how to cope with the issues it does have, and 2) once those issues are coped with, it works better than anything else I know well enough to use now. -- Gwynne