Pull to refresh

Comments 139

Таки Цукерберг сможет всем злопыхателям доказать, что от социальных сетей есть какая-то польза?..
Надо было бы FB на С++ переписать. Или вообще на асме…
Для каждой задачи свои инструменты.
А при рабочем проекте переписывания его с нуля тоже ничего хорошего не принесет.
Тут статья где то было про 3 закона «Как надо программировать». Так вот Вы как раз и предлагаете ими воспользоваться с такими идеями.
Вопрос скорее в том, что если бы с самого начала был бы выбран другой язык, то затраты на программистов и железо могли бы быть меньше.

А переписывать с нуля готовый проект — это огромные риски и затраты, так что, да, ничего хорошего не принесет.
> затраты на программистов и железо могли бы быть меньше.
или могли бы быть больше. пустые слова
Эх, какой талант пропадает! С такими способностями дистанционного мгновенного анализа многомиллионного проекта, вас бы любая компания взяла бы к себе!
Слова «вопрос» и «могли бы» там не просто так написаны.

Одному мне кажется данная новость не нормальной? Не нормально когда писать новый компилятор становится экономически выгоднее. Этот факт должен заставить серьезно задуматься.
Одному Вам.

У Вас очень странный взгляд на мир. Не могу понять, отчего Вы настолько твердо уверены в том, что выбрав другой язык FB не столкнулись бы с такими же, а то и проблемами похуже.

Разработчик FB изначально выбрал средства для реализации своего проекта. Отчего Вам кажется странным стремление эти средства оптимизировать или усовершенствовать?
Вопрос не только и не столько в компиляторе для PHP. До этого FB уже как минимум соптимизировали memcached.
Мне вот интересно, те, якобы умные, люди, которые поставили b00taТik и мне минусы знают что вопреки всем их догмам о крупном рефакторинге Yahoo! успешно перерыгнули с C++ на PHP в 2002м? И как-то ни три закона не помешали, ни погода на Марсе, ни даже фаза Луны. Всё у них получилось.
Возможно на С++ поддерживать такой проект становилось все сложнее и сложнее. Вот они и перепрыгнули.
Почему то они тоже выбрали PHP.
Ага. А в крупном проекте Яву поддерживать проще, чем PHP. Но это секрет, никому не рассказывай.
Ну тогда разработчики FB и Yahoo сделали самую большую ошибку при выборе инструмента для разработки. Или их проекты не такие уж и большие ))))).
В крупном проекте, имхо, важность выбора языка не так важна, как архитектура и грамотные управление и организация процесса.
Я и не говрю что Ява лучше как язык. Преимущество Явы в огромном количестве высококачественных серверных библиотек.
Не исключено :)
Но есть небольшая разница; Керкус — это интерпретатор пхп, а Phalanger интегрирует php в мир .net, транслируя его в CLR-модуль.

Обидно только, что в этом — вся суть php
Quercus вроде в байт-код JVM компилировал PHP. И доступ ко всему стеку Java-технологий также имеется.
Если быть точным, то только в profession version и при указании спец.флага. Т.е. поведение по умолчанию даже при подготовке war-файла — туда пакуется скрипт и интерпретатор к нему, включая реализацию основных либ.
В любом случае, представляемая технология, по видимому, более серьёзная задумка чем вспомогательные интерпретаторы в связке с явой.
О! Любитель синглотонов, уже и тут троллишь
Кто-то с РСДН прибежал, поднасрал и спешно скрылся в Интернетах за маской анонимности. Если уж переходишь на личности, то будь добр предъявить свою.
С удовольствием посмотрел бы на бюджет и сроки проекта уровня фейсбук при реализации его на асме :)
Ну, асм — это слишком, но с их-то ресурсами вполне можно критические места переписать на Си. Скорей всего, так и сделано. В статье говорится о 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%»
Боже, сделай так, чтобы это было хотя бы на половину правдой!
Возможно, компиляция сразу в асм вместо байткода (как V8).
Это была попытка пошутить про наполовину. Черезстрочная компиляция.
«Революционный компилятор анализирует быдлокод и переписывает его оптимально. Прирост производительности составляет 80%, исчезают утечки памяти.»
UFO landed and left these words here
Ну это будет просто прорыв! Лично мне в такое верится с трудом, но если это окажется правдой — будет очень вкусно!
заметка удачно смотрелась бы ровно через два месяца ;)
Возможности серверов увеличиваются, нагрузка уменьшается… Скоро в конце HTML-страниц будет прописываться =)
«created» или «generated», скорее
ибо «loaded» оно может долго, если у человека канал в 5kbps :)
Несовсем. Все же bcompiler создавали немного для другого.
Сначала гугл со своим go. Теперь FB с HPHP. Это что, мода такая у крупных компаний ))
Это потребности. PHP — интерпретируемый язык, из-за этого все сложности. И чем выше нагрузка, тем больше затрат на поддержку. Тут выбор, либо наращивать мощности, либо на 80% ускорить выполнение кода.

Ваш, КО :)
Возможно, кризис удешевил рабочую силу до того уровня, когда стало выгодно допилить код, чем докупить железку.
Код — субстанция гораздо гибкая, чем железо.
код компилируют вручную. Китаец читает код, индус интерпретирует его, выдают хтмл сами сходу.
И так делают миллиард пар.
Это-то все понятно. Довольно интересные закономерностисовпадения.
Кстати, открытый компилятор для PHP уже давно есть, называется Roadsend PHP (roadsend.com).
И его, кстати, тоже переписывают (raven). Примечательно, что они отказались от Bigloo Scheme в пользу C++. Интересно, из каких соображений.
Будет здорово, Если можно будет посмотреть хотя бы отрывки исходных кодов, люблю посмотреть на работу мастеров своего дела, ведь fb не будут нанимать делитантов.Да, на таком коде я думаю есть чем поучиться.Мысли вслух.
в статьях на которые указывают ссылки, сказано, что Facebook переписал не PHP скрипты, а PHP runtime, т.е. интерпретатор, обновленную версию которого они и собираются сделать доступной по опенсорс лицензии.
Ребята из Facebook сделали очень много хорошего.
Эта новость — ещё один повод сказать им большое спасибо.
Было бы здорово, особенно про новую версию языка. Классический PHP уже явно зашёл в какой-то унылый тупик. А тут, возможно, будет свежий взгляд от самых что ни на есть практиков.
Они же не новый язык пишут, не новые концепции в него вводят.
Мы же пока всё равно ничего не знаем. Но слова про «новую версию языка» в конце поста внушают некоторую надежду.

А что вам сейчас не хватает в PHP 5.3? Что не хватает из того, что будет в PHP6?
Это ответ на какой из двух вопросов. Вам сейчас плюс поставил какой-то человек, который, видимо, не знает, что в PHP6 будет полная поддержка Unicode.
На оба. Прозрачной поддержки Unicode нехватает сейчас и она будет в PHP6.
Да, точно, вопрос неправильно задал. Должно быть «из того, что не будет в PHP6».
А я например против всех этих нововведений, те бинарные строки, которые есть сейчас. могут обеспечить лучшую производительность, чем вся эта возня с перекодировками.
Нет, я то обычно работаю с utf8. И мне не лень явно писать mb_strlen() и mb_substr() там, где это требуется, а не всюду.
Согласованности объектной модели, стандарта именования и вызова функций, устранения чехарды с резолвингом имён (которая привела к этим жутким бэкслэшам), 64-битных целых, вообще строгой типизации по желанию программиста (в том числе с примитивными типами, а не только с классами)… Нормальной сборки мусора не хватает (та, что появилась в 5.3, всё равно умудряется отлавливать не все циклические ссылки). Не хватает официальной стандартной системы классов (SPL до сих пор на подпольном положении). Не хватает разыменования массивов (func(x)[1]).

Я уж не буду говорить про всякие маджик-квоты и прочую шелупонь…
> Согласованности объектной модели
Конкретнее?
> стандарта именования и вызова функций
Его вводить поздно.
> странения чехарды с резолвингом имён (которая привела к этим жутким бэкслэшам)
Это вкусовщина. Символ как символ.
> 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 (который сам-то по себе вполне симпатичный язык), и на который народ начнёт потихоньку мигрировать самостоятельно.
А по моему, так ваши претензии к каким-то редко используемым функциям, ну кому там нужна типизация и 64-битные целые? Что гораздо хуже, это уродливый синтаксис, например, массивы объявлять в яваскрипте или Руби куда как удобнее, кроме того в них массивы и строки являются (ну или притворяются) объектами, а в php надо писать все эти уродливые array_*().

Еще хотелось бы более легковесных коллекций, чем тяжелые ассоциативные масивы, и функции для быстрого парсинга строк с плейсхолдерами (типа 'SELECT * FROM ?t WHERE id = ?'), а то сейчас этот парсинг приходится писать руками и он притормаживает. И еще нативную функцию для роутинга запросов в MVC фреймворках, а то это тоже узкий участок :)

Ах, и самое главное — хотелось бы не-перезапускаемую при каждом запросе версию php, так как это ставит серьезные ограничения производительности.

А совместимость — да, зло, по-хорошему надо взять и выпустить не совместимую версию, а хорошую, а то ведь, убегут все на Руби или еще куда-нибудь.
Пардоньте, а что с плейсхолдерами-то? Нафига их вообще парсить? Юзайте PDO и всё Вам будет из коробки. Если какой-то свой язык — найдите нужный PECL для его парсинга… Вот уж PHP как язык тут точно совсем не при чём.
Плейсхолдеры в PDO сделаны для галочки, слишком мало возможностей (нет например, возможности вставить данные из массивов, добавлять к именам полей/таблиц префиксы). Плюс, PDO — лишний уровень абстракции, зачем между библиотекой и БД ставить прослойки?

Кроме того, плейсхолдеры можно использовать и для дргуих целей, например форматирование сообщений.

Так что функция, позволяющая сделать свой «printf» была бы очень полезна.

Есть, правда, preg_replace_callback(), но она не гарантирует порядка вызова колбеков и не передает порядковый номер плейсхолдера в колбек.
UFO landed and left these words here
Вы исходный комментарий не прочли. Sprintf не экранирует спецсимволы в аргументах и не позволяет задать свой обработчик плейсхолдеров.
Собственно, если уж обратную совместимость резать на корню…

то почему сразу не перейти python/ruby?
А зачем делать несовместимый язык «по мотивам»? Не проще взять какой-нибудь Python. Да, у PHP есть ошибки и глупости, про них надо писать разработчикам, а не хихикать тихонько в блоге.
Как я уже «прохихикал» когда-то в блоге, «Ява, JS, Питон и даже, прости господи, Руби сумели сохранить согласованный синтаксис без моего участия, и только за PHP почему-то нужно было следить лично мне»…

Я не работаю в Java, но у Python и JS масса проблем.
Евгений, ну Вы просили сказать, что мне не нравится — я сказал. Я же не настаиваю, что ровно то же должно не нравиться и Вам и всем остальным.

Про Питон ничего не скаже, а какие проблемы у JS в синтаксисе? Кажется, уж там-то всё — проще не придумаешь. Только “with” лишний.
Про Питон есть две отличные статьи на сайте IBM, в JS масса проблем, лишний там, пожалуй, void, with просто недоделанный, в VBscript хороший with.
Ну всё-таки, можно пример с JS? Я его честно считаю одним из лучших скриптовых синтаксисов — минимальное количество языковых конструкций, при этом ими можно выражать буквально что угодно.

void там именно _лишний_ — от него ни вреда ни пользы, а вот with коверкает области видимости, портит понимаемость кода и при этом, в сущности, никакой пользы не приносит. Но поскольку его всё равно особо не используют (именно поэтому), то мне он особо не мешает.
with потому и вредный, что недоделанный. Про JS я просто не помню где и как искать статьи, про Python вспомнил — дал ориентиры.
Про 5.3. тут тоже недавно постинг был во френдленте: dmih.livejournal.com/530068.html

Вот про зенд-оптимайзар — это очень показательно. То есть, у зенда нет до сих пор оптимайзера для головной версии своего же языка. Я не знаю, то ли зенд потерял интерес к php, то ли денег на всё не хватает, то ли разные отделы друг с другом договориться не могут, но это явно НЕ нормальная ситуация.

Хотя я 5.3 вполне юзаю, но вот то, что народ на него ни фига не переходит an mass — это что-то значит.
> Вот про зенд-оптимайзар — это очень показательно. То есть, у зенда нет до сих пор оптимайзера для головной версии своего же языка.
Видимо, это потому что они продвигают новый продукт — Zend Server.
> Хотя я 5.3 вполне юзаю, но вот то, что народ на него ни фига не переходит an mass — это что-то значит.
Народ и на PHP5 ещё не весь перешёл. Это что-то говорит про народ, а не про язык.
да хватит уже защищать пхп. всем давно понятно, что пхп — уг высшей консистенции.
Да хватит уже нападать на PHP, всем давно понятно, что недостатки есть у всех языков, иначе новые не появлялись бы.
Не ругайтесь, в 2х последних комментариях вы оба правы
А также Питон, частично Руби, Яваскрипт и прочая-прочая-прочая. В общем, получится язык, у которого была длительная стадия проектирования.
UFO landed and left these words here
вы думаете что фейсбук это только 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...»
UFO landed and left these words here
основная вычислительная нагрузка — это составление сводки обновлений информации на главной, об этом говорил Александр Москалюк на РИТ 2008.
Ну не может человек настолько не любить свою карму!
Фейсбук показывает, что трудоемкие задачи не только требуют совершенства технологий, но и сами двигают этот процесс. Что может быть лучше?
>Как известно, 90% кода Facebook написано на PHP.

Пруфлинк бы.
Hadoop на jave, чат на erlang'e, много чего вроде мемкешед, а переписанного на С…

И после вычета всего этого 90% остается?
Фронт-енд имеется в виду. Если почитать оригинал, там указано явно, что речь идет про фронт-енд
Чат, положим, не только на Эрланге. Но это, конечно, занудство :)
ну уж если совсем нудеть, то еще js вспомним
:-)

Солидная серверная часть чата на Си. Хотя не все ли равно на чем?
Во-первых для таких задач давно есть компиляторы в байт-код. А если имеется в виду компилятор под нативную платформу, то для PHP и любого другого динамического языка это принципиально невозможно. Ибо есть eval например ;)
Причины могут быть, но уж точно не в eval.

eval — всего-лишь запуск компилятора и выполнение полученного кода, для компилируемых языков.
Очень интересно. А как же тогда V8 компиляет JS в нативный код? Ведь в JS'е есть eval :)
HPHP — PHP с блекджеком и шлюхами… и надеюсь со строгой типизацией :)
1) Бедный vkontakte. тоже придется с zend конкурировать )))
2) Чисто по ощущениям, переписывать PHP они не возьмутся (facebook конечно, но...)
3) Не забудьте плюсануть, если это будет туча расширений + FBxcache какой нибудь. Ну а пока минусуйте на здоровье )))))

В любом случае ребятам флаг в руки. Если пишут компилятор, то это явно оздоровление ситуации с PHP как таковым. Даешь конкуренцию!
Если Facebook переписывает php, это значит только одно — php не годится даже в качестве «компонента» для приложений аналогичного масштаба (проектов по меньше — тоже)!!! (FB не написан на 100% на php, где php используется ТОЛЬКО в качестве «клея»), весь кор который как раз то и берет на себя всю нагрузку — разработан на Java

А новый FBphp — это скорее будет что-то типа «виртуалмашин» Quercus (quercus.caucho.com) по принципу — пишем на php, получаем Java (сразу встает вопрос, нафига писать тогда на пэхапы)

еще есть придуманный Facebook язык разработки FB приложений — FBML
!!!

P.S. Не понятно каким образом содержание новости связано с вашим выводом, видимо вы тут руководствовались все чем угодно, но только не логикой.
Для этого им придеться уничтожить главную фитчу пхп — возможность сложить строку и число. А тогда миллионы быдлокодеров не смогут на этом HPPHP кодить )
Only those users with full accounts are able to leave comments. Log in, please.