Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 139
Надо было бы FB на С++ переписать. Или вообще на асме…
На Java будет достаточно.
ASP.Net тоже сгодился бы :-)
Для каждой задачи свои инструменты.
А при рабочем проекте переписывания его с нуля тоже ничего хорошего не принесет.
Тут статья где то было про 3 закона «Как надо программировать». Так вот Вы как раз и предлагаете ими воспользоваться с такими идеями.
А при рабочем проекте переписывания его с нуля тоже ничего хорошего не принесет.
Тут статья где то было про 3 закона «Как надо программировать». Так вот Вы как раз и предлагаете ими воспользоваться с такими идеями.
Вопрос скорее в том, что если бы с самого начала был бы выбран другой язык, то затраты на программистов и железо могли бы быть меньше.
А переписывать с нуля готовый проект — это огромные риски и затраты, так что, да, ничего хорошего не принесет.
А переписывать с нуля готовый проект — это огромные риски и затраты, так что, да, ничего хорошего не принесет.
> затраты на программистов и железо могли бы быть меньше.
или могли бы быть больше. пустые слова
или могли бы быть больше. пустые слова
Эх, какой талант пропадает! С такими способностями дистанционного мгновенного анализа многомиллионного проекта, вас бы любая компания взяла бы к себе!
Слова «вопрос» и «могли бы» там не просто так написаны.
Одному мне кажется данная новость не нормальной? Не нормально когда писать новый компилятор становится экономически выгоднее. Этот факт должен заставить серьезно задуматься.
Одному мне кажется данная новость не нормальной? Не нормально когда писать новый компилятор становится экономически выгоднее. Этот факт должен заставить серьезно задуматься.
Одному Вам.
У Вас очень странный взгляд на мир. Не могу понять, отчего Вы настолько твердо уверены в том, что выбрав другой язык FB не столкнулись бы с такими же, а то и проблемами похуже.
Разработчик FB изначально выбрал средства для реализации своего проекта. Отчего Вам кажется странным стремление эти средства оптимизировать или усовершенствовать?
Вопрос не только и не столько в компиляторе для PHP. До этого FB уже как минимум соптимизировали memcached.
У Вас очень странный взгляд на мир. Не могу понять, отчего Вы настолько твердо уверены в том, что выбрав другой язык FB не столкнулись бы с такими же, а то и проблемами похуже.
Разработчик FB изначально выбрал средства для реализации своего проекта. Отчего Вам кажется странным стремление эти средства оптимизировать или усовершенствовать?
Вопрос не только и не столько в компиляторе для PHP. До этого FB уже как минимум соптимизировали memcached.
Мне вот интересно, те, якобы умные, люди, которые поставили b00taТik и мне минусы знают что вопреки всем их догмам о крупном рефакторинге Yahoo! успешно перерыгнули с C++ на PHP в 2002м? И как-то ни три закона не помешали, ни погода на Марсе, ни даже фаза Луны. Всё у них получилось.
Возможно на С++ поддерживать такой проект становилось все сложнее и сложнее. Вот они и перепрыгнули.
Почему то они тоже выбрали PHP.
Почему то они тоже выбрали PHP.
Ага. А в крупном проекте Яву поддерживать проще, чем PHP. Но это секрет, никому не рассказывай.
Берите лучшее из двух миров: phalanger.codeplex.com/
Не исключено :)
Но есть небольшая разница; Керкус — это интерпретатор пхп, а Phalanger интегрирует php в мир .net, транслируя его в CLR-модуль.
Обидно только, что в этом — вся суть php
Но есть небольшая разница; Керкус — это интерпретатор пхп, а Phalanger интегрирует php в мир .net, транслируя его в CLR-модуль.
Обидно только, что в этом — вся суть php
Quercus вроде в байт-код JVM компилировал PHP. И доступ ко всему стеку Java-технологий также имеется.
О! Любитель синглотонов, уже и тут троллишь
С удовольствием посмотрел бы на бюджет и сроки проекта уровня фейсбук при реализации его на асме :)
или на java…
Ну, асм — это слишком, но с их-то ресурсами вполне можно критические места переписать на Си. Скорей всего, так и сделано. В статье говорится о 80% кода на php, остальное, возможно, на чём-то более производительном.
A week ago, I let ya'll know that the core PHP team had been brought to Facebook's main campus
Если я правильно понимаю, разработкой занимаются основные программисты самого PHP, а не Facebook…
Я думаю, что имелось в виду «ядро команды PHP-разработчиков» или «основная команда PHP-разработчиков».Хотя с моими знаниями английского…
отсюда:
Мне все же кажется, что это сторонняя команда ))
I've heard that a whole gaggle of PHP core developers were invited to Facebook's offices today to discuss some grand new open-source project from Facebook.
Мне все же кажется, что это сторонняя команда ))
Нет не правильно. Просто коре-тим PHP пригласили в фейсбук, чтобы рассказать им о том, что используют переписанны интерпретатор php ( по некоторым данным, нагрузка снизилась в пять раз) и более того, готовы сделать это достоянием общественности — тобишь поделиться со всеми и возможно в последующим заменить нативную (текущую) версию интерпретатора :)
«на 80%»
Боже, сделай так, чтобы это было хотя бы на половину правдой!
Боже, сделай так, чтобы это было хотя бы на половину правдой!
Ну это будет просто прорыв! Лично мне в такое верится с трудом, но если это окажется правдой — будет очень вкусно!
заметка удачно смотрелась бы ровно через два месяца ;)
Возможности серверов увеличиваются, нагрузка уменьшается… Скоро в конце HTML-страниц будет прописываться =)
я не занудствую, но я так понял это аналог bcompiler?
вот бы аналог V8 для javascript
Сначала гугл со своим go. Теперь FB с HPHP. Это что, мода такая у крупных компаний ))
Хотя вру — сначала был не гугл…
Это потребности. PHP — интерпретируемый язык, из-за этого все сложности. И чем выше нагрузка, тем больше затрат на поддержку. Тут выбор, либо наращивать мощности, либо на 80% ускорить выполнение кода.
Ваш, КО :)
Ваш, КО :)
Кстати, открытый компилятор для PHP уже давно есть, называется Roadsend PHP (roadsend.com).
Будет здорово, Если можно будет посмотреть хотя бы отрывки исходных кодов, люблю посмотреть на работу мастеров своего дела, ведь fb не будут нанимать делитантов.Да, на таком коде я думаю есть чем поучиться.Мысли вслух.
в статьях на которые указывают ссылки, сказано, что Facebook переписал не PHP скрипты, а PHP runtime, т.е. интерпретатор, обновленную версию которого они и собираются сделать доступной по опенсорс лицензии.
Ребята из Facebook сделали очень много хорошего.
Эта новость — ещё один повод сказать им большое спасибо.
Эта новость — ещё один повод сказать им большое спасибо.
Было бы здорово, особенно про новую версию языка. Классический PHP уже явно зашёл в какой-то унылый тупик. А тут, возможно, будет свежий взгляд от самых что ни на есть практиков.
Они же не новый язык пишут, не новые концепции в него вводят.
А что вам сейчас не хватает в PHP 5.3? Что не хватает из того, что будет в PHP6?
Unicode.
Это ответ на какой из двух вопросов. Вам сейчас плюс поставил какой-то человек, который, видимо, не знает, что в PHP6 будет полная поддержка Unicode.
А я например против всех этих нововведений, те бинарные строки, которые есть сейчас. могут обеспечить лучшую производительность, чем вся эта возня с перекодировками.
Согласованности объектной модели, стандарта именования и вызова функций, устранения чехарды с резолвингом имён (которая привела к этим жутким бэкслэшам), 64-битных целых, вообще строгой типизации по желанию программиста (в том числе с примитивными типами, а не только с классами)… Нормальной сборки мусора не хватает (та, что появилась в 5.3, всё равно умудряется отлавливать не все циклические ссылки). Не хватает официальной стандартной системы классов (SPL до сих пор на подпольном положении). Не хватает разыменования массивов (func(x)[1]).
Я уж не буду говорить про всякие маджик-квоты и прочую шелупонь…
Я уж не буду говорить про всякие маджик-квоты и прочую шелупонь…
> Согласованности объектной модели
Конкретнее?
> стандарта именования и вызова функций
Его вводить поздно.
> странения чехарды с резолвингом имён (которая привела к этим жутким бэкслэшам)
Это вкусовщина. Символ как символ.
> 64-битных целых
это есть
> вообще строгой типизации по желанию программиста (в том числе с примитивными типами, а не только с классами)
Почему вы считаете, что это делать надо. Массив, кстати, можно указать.
> та, что появилась в 5.3, всё равно умудряется отлавливать не все циклические ссылки
Баг вы уже завели на bugs.php.net?
> Не хватает официальной стандартной системы классов (SPL до сих пор на подпольном положении).
Он не подпольный, просто плохо документирован. Но вы можете помочь проекту.
> Не хватает разыменования массивов (func(x)[1]).
в PHP6 будет
> Я уж не буду говорить про всякие маджик-квоты и прочую шелупонь
Чего уж там, говорите :)
Конкретнее?
> стандарта именования и вызова функций
Его вводить поздно.
> странения чехарды с резолвингом имён (которая привела к этим жутким бэкслэшам)
Это вкусовщина. Символ как символ.
> 64-битных целых
это есть
> вообще строгой типизации по желанию программиста (в том числе с примитивными типами, а не только с классами)
Почему вы считаете, что это делать надо. Массив, кстати, можно указать.
> та, что появилась в 5.3, всё равно умудряется отлавливать не все циклические ссылки
Баг вы уже завели на bugs.php.net?
> Не хватает официальной стандартной системы классов (SPL до сих пор на подпольном положении).
Он не подпольный, просто плохо документирован. Но вы можете помочь проекту.
> Не хватает разыменования массивов (func(x)[1]).
в PHP6 будет
> Я уж не буду говорить про всякие маджик-квоты и прочую шелупонь
Чего уж там, говорите :)
По согласованности: изнутри кода встроенные объекты не должны отличаться от созданных руками. Сейчас это не так. Следствия: david-m.livejournal.com/958866.html, david-m.livejournal.com/963762.html. По примитивным типам: david-m.livejournal.com/1117497.html.
По вкусовщине: david-m.livejournal.com/964716.html, david-m.livejournal.com/1125158.html. Может конкретно бэкслэши и вкусовщина, но перегруженность синтаксиса налицо.
Мне не особо интересно обсуждать гипотезы, я в PHP — пользователь (языка), а не разработчик. Вся натужность последних нововведений однозначно указывает, что у PHP гигантские проблемы совместимости с плохо продуманной ранней архитектурой, которая не позволяет улучшать язык без проливания вёдер крови.
По большинству перечисленного ситуация «вводить поздно». Поэтому я и надеюсь, что у кого-то достанет сил сделать НЕсовместимый в обратную сторону язык по мотивам PHP (который сам-то по себе вполне симпатичный язык), и на который народ начнёт потихоньку мигрировать самостоятельно.
По вкусовщине: david-m.livejournal.com/964716.html, david-m.livejournal.com/1125158.html. Может конкретно бэкслэши и вкусовщина, но перегруженность синтаксиса налицо.
Мне не особо интересно обсуждать гипотезы, я в PHP — пользователь (языка), а не разработчик. Вся натужность последних нововведений однозначно указывает, что у PHP гигантские проблемы совместимости с плохо продуманной ранней архитектурой, которая не позволяет улучшать язык без проливания вёдер крови.
По большинству перечисленного ситуация «вводить поздно». Поэтому я и надеюсь, что у кого-то достанет сил сделать НЕсовместимый в обратную сторону язык по мотивам PHP (который сам-то по себе вполне симпатичный язык), и на который народ начнёт потихоньку мигрировать самостоятельно.
P. S. Точки приклеились к ссылкам, парсер лох:(
А по моему, так ваши претензии к каким-то редко используемым функциям, ну кому там нужна типизация и 64-битные целые? Что гораздо хуже, это уродливый синтаксис, например, массивы объявлять в яваскрипте или Руби куда как удобнее, кроме того в них массивы и строки являются (ну или притворяются) объектами, а в php надо писать все эти уродливые array_*().
Еще хотелось бы более легковесных коллекций, чем тяжелые ассоциативные масивы, и функции для быстрого парсинга строк с плейсхолдерами (типа 'SELECT * FROM ?t WHERE id = ?'), а то сейчас этот парсинг приходится писать руками и он притормаживает. И еще нативную функцию для роутинга запросов в MVC фреймворках, а то это тоже узкий участок :)
Ах, и самое главное — хотелось бы не-перезапускаемую при каждом запросе версию php, так как это ставит серьезные ограничения производительности.
А совместимость — да, зло, по-хорошему надо взять и выпустить не совместимую версию, а хорошую, а то ведь, убегут все на Руби или еще куда-нибудь.
Еще хотелось бы более легковесных коллекций, чем тяжелые ассоциативные масивы, и функции для быстрого парсинга строк с плейсхолдерами (типа 'SELECT * FROM ?t WHERE id = ?'), а то сейчас этот парсинг приходится писать руками и он притормаживает. И еще нативную функцию для роутинга запросов в MVC фреймворках, а то это тоже узкий участок :)
Ах, и самое главное — хотелось бы не-перезапускаемую при каждом запросе версию php, так как это ставит серьезные ограничения производительности.
А совместимость — да, зло, по-хорошему надо взять и выпустить не совместимую версию, а хорошую, а то ведь, убегут все на Руби или еще куда-нибудь.
Пардоньте, а что с плейсхолдерами-то? Нафига их вообще парсить? Юзайте PDO и всё Вам будет из коробки. Если какой-то свой язык — найдите нужный PECL для его парсинга… Вот уж PHP как язык тут точно совсем не при чём.
Плейсхолдеры в PDO сделаны для галочки, слишком мало возможностей (нет например, возможности вставить данные из массивов, добавлять к именам полей/таблиц префиксы). Плюс, PDO — лишний уровень абстракции, зачем между библиотекой и БД ставить прослойки?
Кроме того, плейсхолдеры можно использовать и для дргуих целей, например форматирование сообщений.
Так что функция, позволяющая сделать свой «printf» была бы очень полезна.
Есть, правда, preg_replace_callback(), но она не гарантирует порядка вызова колбеков и не передает порядковый номер плейсхолдера в колбек.
Кроме того, плейсхолдеры можно использовать и для дргуих целей, например форматирование сообщений.
Так что функция, позволяющая сделать свой «printf» была бы очень полезна.
Есть, правда, preg_replace_callback(), но она не гарантирует порядка вызова колбеков и не передает порядковый номер плейсхолдера в колбек.
Собственно, если уж обратную совместимость резать на корню…
то почему сразу не перейти python/ruby?
то почему сразу не перейти python/ruby?
А зачем делать несовместимый язык «по мотивам»? Не проще взять какой-нибудь Python. Да, у PHP есть ошибки и глупости, про них надо писать разработчикам, а не хихикать тихонько в блоге.
Как я уже «прохихикал» когда-то в блоге, «Ява, JS, Питон и даже, прости господи, Руби сумели сохранить согласованный синтаксис без моего участия, и только за PHP почему-то нужно было следить лично мне»…
Я не работаю в Java, но у Python и JS масса проблем.
Евгений, ну Вы просили сказать, что мне не нравится — я сказал. Я же не настаиваю, что ровно то же должно не нравиться и Вам и всем остальным.
Про Питон ничего не скаже, а какие проблемы у JS в синтаксисе? Кажется, уж там-то всё — проще не придумаешь. Только “with” лишний.
Про Питон ничего не скаже, а какие проблемы у JS в синтаксисе? Кажется, уж там-то всё — проще не придумаешь. Только “with” лишний.
Про Питон есть две отличные статьи на сайте IBM, в JS масса проблем, лишний там, пожалуй, void, with просто недоделанный, в VBscript хороший with.
Ну всё-таки, можно пример с JS? Я его честно считаю одним из лучших скриптовых синтаксисов — минимальное количество языковых конструкций, при этом ими можно выражать буквально что угодно.
void там именно _лишний_ — от него ни вреда ни пользы, а вот with коверкает области видимости, портит понимаемость кода и при этом, в сущности, никакой пользы не приносит. Но поскольку его всё равно особо не используют (именно поэтому), то мне он особо не мешает.
void там именно _лишний_ — от него ни вреда ни пользы, а вот with коверкает области видимости, портит понимаемость кода и при этом, в сущности, никакой пользы не приносит. Но поскольку его всё равно особо не используют (именно поэтому), то мне он особо не мешает.
Про 5.3. тут тоже недавно постинг был во френдленте: dmih.livejournal.com/530068.html
Вот про зенд-оптимайзар — это очень показательно. То есть, у зенда нет до сих пор оптимайзера для головной версии своего же языка. Я не знаю, то ли зенд потерял интерес к php, то ли денег на всё не хватает, то ли разные отделы друг с другом договориться не могут, но это явно НЕ нормальная ситуация.
Хотя я 5.3 вполне юзаю, но вот то, что народ на него ни фига не переходит an mass — это что-то значит.
Вот про зенд-оптимайзар — это очень показательно. То есть, у зенда нет до сих пор оптимайзера для головной версии своего же языка. Я не знаю, то ли зенд потерял интерес к php, то ли денег на всё не хватает, то ли разные отделы друг с другом договориться не могут, но это явно НЕ нормальная ситуация.
Хотя я 5.3 вполне юзаю, но вот то, что народ на него ни фига не переходит an mass — это что-то значит.
> Вот про зенд-оптимайзар — это очень показательно. То есть, у зенда нет до сих пор оптимайзера для головной версии своего же языка.
Видимо, это потому что они продвигают новый продукт — Zend Server.
> Хотя я 5.3 вполне юзаю, но вот то, что народ на него ни фига не переходит an mass — это что-то значит.
Народ и на PHP5 ещё не весь перешёл. Это что-то говорит про народ, а не про язык.
Видимо, это потому что они продвигают новый продукт — Zend Server.
> Хотя я 5.3 вполне юзаю, но вот то, что народ на него ни фига не переходит an mass — это что-то значит.
Народ и на PHP5 ещё не весь перешёл. Это что-то говорит про народ, а не про язык.
Блин. А ведь тогда ASP.NET получается :)
В фейсбуке только фронт написан на php.
вы думаете что фейсбук это только php и БД?
memcache, Thrift, Hive, Cassandra, Scribe и пр., бэкенд почти весь C++
большинство их проектов опенсорс developers.facebook.com/opensource.php.
Минусующим: вторая ссылка в гугле blog.facebook.com/blog.php?post=2356432130
«You might have noticed that the user-facing portion of Facebook is written in PHP...»
memcache, Thrift, Hive, Cassandra, Scribe и пр., бэкенд почти весь C++
большинство их проектов опенсорс developers.facebook.com/opensource.php.
Минусующим: вторая ссылка в гугле blog.facebook.com/blog.php?post=2356432130
«You might have noticed that the user-facing portion of Facebook is written in PHP...»
На Hyper-PHP можно будет писать Hyper-быдлокод.
Фейсбук показывает, что трудоемкие задачи не только требуют совершенства технологий, но и сами двигают этот процесс. Что может быть лучше?
>Как известно, 90% кода Facebook написано на PHP.
Пруфлинк бы.
Hadoop на jave, чат на erlang'e, много чего вроде мемкешед, а переписанного на С…
И после вычета всего этого 90% остается?
Пруфлинк бы.
Hadoop на jave, чат на erlang'e, много чего вроде мемкешед, а переписанного на С…
И после вычета всего этого 90% остается?
Во-первых для таких задач давно есть компиляторы в байт-код. А если имеется в виду компилятор под нативную платформу, то для PHP и любого другого динамического языка это принципиально невозможно. Ибо есть eval например ;)
Причины могут быть, но уж точно не в eval.
eval — всего-лишь запуск компилятора и выполнение полученного кода, для компилируемых языков.
eval — всего-лишь запуск компилятора и выполнение полученного кода, для компилируемых языков.
Очень интересно. А как же тогда V8 компиляет JS в нативный код? Ведь в JS'е есть eval :)
для PHP и любого другого динамического языка это принципиально невозможно.ORLY? Ну вот вам, www.macruby.org/blog/2010/01/31/macruby05.html почитайте раздел «More Elegant Ahead-of-Time Compilation»
HPHP — PHP с блекджеком и шлюхами… и надеюсь со строгой типизацией :)
Когда анонсируют — свистните.
Следующей после HPHP должен стать PHPHP.
1) Бедный vkontakte. тоже придется с zend конкурировать )))
2) Чисто по ощущениям, переписывать PHP они не возьмутся (facebook конечно, но...)
3) Не забудьте плюсануть, если это будет туча расширений + FBxcache какой нибудь. Ну а пока минусуйте на здоровье )))))
В любом случае ребятам флаг в руки. Если пишут компилятор, то это явно оздоровление ситуации с PHP как таковым. Даешь конкуренцию!
2) Чисто по ощущениям, переписывать PHP они не возьмутся (facebook конечно, но...)
3) Не забудьте плюсануть, если это будет туча расширений + FBxcache какой нибудь. Ну а пока минусуйте на здоровье )))))
В любом случае ребятам флаг в руки. Если пишут компилятор, то это явно оздоровление ситуации с PHP как таковым. Даешь конкуренцию!
Если Facebook переписывает php, это значит только одно — php не годится даже в качестве «компонента» для приложений аналогичного масштаба (проектов по меньше — тоже)!!! (FB не написан на 100% на php, где php используется ТОЛЬКО в качестве «клея»), весь кор который как раз то и берет на себя всю нагрузку — разработан на Java
А новый FBphp — это скорее будет что-то типа «виртуалмашин» Quercus (quercus.caucho.com) по принципу — пишем на php, получаем Java (сразу встает вопрос, нафига писать тогда на пэхапы)
еще есть придуманный Facebook язык разработки FB приложений — FBML
А новый FBphp — это скорее будет что-то типа «виртуалмашин» Quercus (quercus.caucho.com) по принципу — пишем на php, получаем Java (сразу встает вопрос, нафига писать тогда на пэхапы)
еще есть придуманный Facebook язык разработки FB приложений — FBML
Для этого им придеться уничтожить главную фитчу пхп — возможность сложить строку и число. А тогда миллионы быдлокодеров не смогут на этом HPPHP кодить )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Facebook создаёт компилятор PHP?