Переосмысление Zephir

[Davert]

Оперативно вы! Супер. Я отписался по ссылке…

Словом, то что творят ребята из Phalcon невероятно. И да, мне нравится возможность на выбор упаковывать библиотеки в extension или подключать их как PHP классы

[hell0w0rd]

Ну вот я не совсем согласен, что это нужно.
С одной стороны таким образом zephir получит огромную популярность, особенно если ребята из jetbrains помогут. Мы действительно получим любую фичу, которой не достает в php и не будем задумываться о совместимости между версиями.
С другой стороны сейчас не совсем подходящее время и некоторая часть зефира остается за кадром. Например мысль о том, что теперь-то мы сможем запустить phalcon на своем шаред хостинге за 100 рублей — не верна. Есть некоторые вещи, которые как писались — так и продолжают писаться пол phalcon на Си. Например volt.
Так что на мой взгляд фича нужная, понятно что к этому когда-то бы пришли, но сейчас есть более важные штуки)

[Davert]

Да, согласен, разработчикм Zephir стоит самим оценивать силы и приориеты. Мы конечно можем хотеть всего и сразу, но сколько всё это займет времени и сил.

Я лично за вариант с мета-языком, так как до выхода Zephir уже можно начать формировать его экосистему — писать либы и фреймворки. При этом эти фреймворки и библиотеки будут такой же частью достоянием всего PHP сообщества.

[AmdY]

Не понятна целевая группа. Те кому нужны миллисекунды перепишут код на си, сэкономив ещё больше. Те кто не силён в си, вряд ли будет лезть в код, а чужие экстеншины его будут пугать из-за проблем с поддержкой, багами и совместимостью с новыми версиями самого php. Ну и как бы уже есть pecl, которым почти никто не пользуется, а кто пользуется — форкает и патчит под себя.
Генерация php — очень сомнительное удовольствие.

[eXTreMeHawk]

Уже есть один отличный, проверенный временем, очень быстрый статически типизированный язык. На нём пишут как софт для корпораций и банков (высокочастотный трейдинг, где важны наносекунды), так и распределённые базы данных, пример — cassandra. Ну зачем ещё увеличивать энтропию и делать из php, который задумывался для совсем других целей, вот такого франкенштейна?

[FanatPHP]

С чисто практической точки зрения я скорее согласен с этим утверждением.
Но с методологической, или, даже — философской…

— Уже есть один отличный, проверенный временем тип орудий. Им разделывают шкуры мамонтов, рубят деревья, убивают зверей на охоте. Ну зачем ещё увеличивать энтропию и делать из блестящего, но бесполезного металла, который задумывался исключительно для украшений, вот такого франкенштейна?

На самом деле пути эволюции неисповедимы. В мире разработаки она, собственно, только и держится на энтузиазме. И это прекрасно. Без проб и ошибок нет и развития. При этом никто не может предсказать, что получится в итоге. Никто. В этом-то и прелесть. Поэтому обязательно надо пробовать новое. Разумеется, некоторые ростки обязательно окажутся тупиковыми. Ничего страшного — это так и задумано. Важно понимать, что без тупиковых ветвей не бывает прорывов. Так что безумству храбрых стоит петь песню, а не держать их за штаны и не пущать.

PS. Ну зачем ещё увеличивать энтропию и делать из Perl, который задумывался для совсем других целей, вот такого франкенштейна — набор утилит Pretty Home Page / Form Interpreter? ;)

[vshemarov]

Писать код с использованием всех этих вкусностей (статическая типизация, именованные параметры и проч.) и получать на выходе «чистый» PHP — идея заманчивая. Но возникает вопрос — а какой ценой? Боюсь, выходной код не всегда будет оптимальным. Но при компиляции C-библиотек это с лихвой перекрывается тем, что сам код на C выполняется в разы быстрее.

А вот при трансляции мета-кода в PHP есть опасения, что производительность будет ниже, чем если то же самое писать сразу на PHP.

[hell0w0rd]

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

// zephir
public function a(string b) {}
// php:
public function a($b) {}
public function a($b) {
if (gettype($b)!== 'string'){...}
}

В первом случае проверки будут только на этапе компиляции
И я с вами не согласен, посмотрите на код, генерируемый зефиром — там все оптимизированно, и будет продолжать оптимизироваться

[vshemarov]

Я же не утверждаю, я лишь высказываю опасения. С Зефиром пока не работал, основываюсь исключительно на том, что, как правило, выигрыш в одном почти неизбежно влечет за собой проигрыш в другом. Но если разработчики смогут реализовать идею, и при этом не потерять в производительности при трансляции в PHP — то это будет реально крутая вещь. И убежден — это может оказать сильнейшее влияние на среду веб разработки