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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
