как вы думаете, почему проекты высокой нагрузки (фб, вк) написаны на рнр и не тормозят?

Ээээ.. Не понял вопроса. Системный интегратор == enterprise-сектор, как правило. Поправьте, если ошибаюсь.

Так вот, заниматься разработкой ПО в рамках компании-системного интегратора, я бы не стал.

Так понятно?

потому-что сервисы писала не школота и их можно масштабировать не ломая архитектуру.

Разве Цукерберг и Дуров не студентотой это все начали писать? А студентота — это такая школота, только с вредными привычками и ЧСВ :3

Угу, так понятно.

Писать можно с кем угодно, главное архитектор должен разрулить все так чтобы рефакторинг в ближайшие лет 10 не понадобился.

PHP очень старается казаться нормальным языком, очень. Но получается плохо

ты тоже очень стараешься. молодец. ;)

Рефакторинг по-любому понадобится. Потому что когда захочешь добавить что-то новое, обнаружится способ более правильно расставить под него иерархию. И наоборот тоже — когда что-то удаляешь, некоторые вещи становятся ненужными и должны быть объединены в общие модули.

Рефакторинг по-любому понадобится.

Ну во первах «все нафиг отрефакторить» и поменять пару интерфейсов - это разной степени пипец.

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

Точно также из java, c# и прочих дергают sql в чем разница с пехепе?

В том, что в жабе и додиезе Prepared Statement действительно выполняется на стороне SQL-сервера.

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

Это тоже не есть хорошо, потому что ты тратишь лишнее время на организацию вещей, которые могут никогда не понадобиться. Одно дело не писать говнокод, и другое дело проектировать сортир со сложностью атомной станции.

Но для этого нужно предусмотреть чуть ли не _все_

Пока ты будешь предусматривать, задачи потеряют актуальность :) Рефакторинг - нормальная часть рабочего процесса. Главное - не копить говно, а рефакторить плохой код как можно быстрее. Именно для этого старшие товарищи делают code review

Да, и про php ты мало знаешь, это полноценный язык, и там есть компиляция в байткод.

причем, 3 разными, не совместимыми между собой реализациями, ни одна из которых в php-source.x.y.z.tar.gz не входит, а за одну Zogd даже денег хочет, да?

А в пыхе нет? :)) У меня сегодня прямо день открытий

Это какие же это реализации? оО И как они должны совмещаться между собой?

Согласен насчет code review, мы тоже не так давно начали в нашей команде, наконец, его нормально практиковать. Вообще от банального code review и обязательного наличия stable-бранча пользы очень много. Лишь бы отдельные товарищи не рвались навязать свое видение архитектуры :)

А, понял. Ты про Zend Encoder и прочую ересь? Чувак, ты вообще не в теме, там немного о другом говорят

Лишь бы отдельные товарищи не рвались навязать свое видение архитектуры

Для этого есть архитектор, мнение которого является решающим

Это если архитектор - отдельная позиция. А в довольно большой части случаев команда состоит из более-менее равноранговых инженеров.

Ну тимлид, сеньор или кто-то вроде все равно должны быть? Тут вопрос поворачивается другим боком - кого будут любить, если из-за архитектурного косяка система встанет раком в прайм-тайм?

А ты пробовал знакомиться за пределами Киевско-Ленинградско-Ярославско-Волгоградского Большого Кольца?

Об этом в свое время неплохо писал Андрей Светлов - кто stable повалил, тот его и чинит, чтобы все тесты проходили, и пока не починит - ничего нового туда больше не мержится. А про тимлида спорно, бывает и так, что тимлид больше менеджер, чем непосредственно разработчик.

с точки зрения практической пользы, как можно полноценно работать с

- кастрированным argument type hinting

- неконсистентностью имен функций и порядка аргументов функций одной категории/схожего назначения

и т.д. по списку «Фрактала»

http://lxr.php.net/xref/PHP_5_4/ext/pdo_mysql/mysql_driver.c#590

Теперь давай, на вскидку, сколько процентов проектов на пыхе осчастливлены тем, что их создатели в курсе?

Одна берется на том же сайте, где родина пыха, она платная, имя ей Optimizer, кажется. Вторая называется accelerator, ЕМНИП. Еще была какая-то со словом Iron в названии. И, насколько помню, самая мякутка в том, что все три перехватывают чтение файла .php, и вот здесь кроется весь косяк: перехватывать всеми тремя модулями по очереди не получится (пруфов не дам), т.о. не получится совместить батарейки, скомпиленные разными компиляторами.

А ты пробовал знакомиться за пределами Киевско-Ленинградско-Ярославско-Волгоградского Большого Кольца?

Я за его пределами живу вообще-то.

там немного о другом говорят

В пыхе даже собственное представление о том, что есть «компиляция в байткод»? Или речь даже о такой НЁХ как «компиляция в байткод ради компиляции в байткод»? Если первое, то подозреваю, что php core team сидит на Vaio, т.к. сони даже слоган использовала «нашущербныйносупердорогойноутбук или такой же, как все?»

Тогда очень странно.

Zend Optimizer — это не отдельная реализация.

mysqli. Там все ок с Prepared Statements.

Но с PDO да, жопочка какая-то.. Да и код там какой.. Странный :)

Zend Optimizer - это раскодировщик исходников, которые были закодированы с помощью Zend Guard. Дабы можно было распространять софт, не стыдясь того говнокода, который там понаписан.

А в треде речь про кеширующие оптимизаторы байт-кода типа APC или eAccelerator

The Zend Optimizer is available free of charge, from the Zend Store, http://www.zend.com/store/products/zend-optimizer.php

отсюда

Таки отдельная. С платностью наврал, да.

Там как раз график, наглядно иллюстрирующий то, про что я говорил. Оказалось оно такой херней болело ажно до 5.3.

Самое вкусное из чейнджлога последней альфы 5.5 (скоро уже должна релизнуться по идее):

А юникод и строки то нормальные будут или опять нет :-)

PHP не надо рассматривать до версии 5.3. Одно унылое говно.

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

В пдф в предыдущем посте написано, что оптимайзер и сам может байткод генерить, но я не ставил, может, Расмус опять разводит, а генерация есть алиас на store.zend.com/buy/guard.php

А юникод и строки то нормальные будут или опять нет :-)

Думаю, что опять нет :)

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

Примерно по тем же причинам и я от него отказался. Но на данный момент динамика, вроде, положительная

А юникод и строки то нормальные будут или опять нет :-)

Их пока только в жабе нормальные видел: все, что внутри VM - строго UTF-16. Не раскодировал - на кладбище (потому что строки нет, есть byte[]), раскодировал неправильно - на кладбище (хотя тут раньше исключение будет, не обработал - на кладбище опять же).

Ну вроде как да, может.. Но по факту все почему-то юзают APC, ходили слухи, что его даже в core воткнут, но щас пробежался по исходникам, не нашел

А еще есть Zend Server и Zend Optimizer+

Что это такое я даже думать не хочу, если честно :) Но судя по zend.com - все крутится вокруг оптимизаций и раскодировки продуктов жизнедеятельности этого самого Zend Guard, за который как раз денег хотят

Ты не шаришь, не на организацию, а на закладывание точек расширения. это гораздо веселее и почти не требует затрат.

Самый тупой пример

interface Processor {
  Result process(Session sess, Data data);
}

Это плохо и нерасширяемо. Когда тебе понадобится вкорячить еще один параметр (да, да) то тебя ждет один из самых неприятных видов рефакторинг, а то и вовсе придется добавить Processor2 - хехе.

interface Processor {
  Result process(ProcessContext ctx);
}

class ProcessContext {
  Session sess;
  Data data;
  ProcessorConfiguration config;//а это мы и добавили, допустим
//а можно еще дофига вкорячить, никто не заметит разницы!
}

На самом деле в том что в жабе есть JDBC а в C# тоже какойто аналог (или даже не один?)

В додиезе ODBC вроде как, его же, ЕМНИП, все мастдайные поделки используют?.. Но могу ошибаться.

Пока ты будешь предусматривать, задачи потеряют актуальность :)

Похоже я неправильно выразился, предусмотреть не задачи, а то ка _может_ поменяться код, и соответственно не позволить там разрастись нерасширяемому коду. Пример в моем посте выше

Они меня пугают у них то ADO то ODBC потому я и непомню, хотя на ем раньше писал.

А так да для win это win использовать общесистемный интерфейс доступа к субд.

Ну значит ты хороший надежный разработчик, на мой взгляд :) Такие нынче редкость.

Но и такой код приходится рефакторить, поверь на слово

DAO используется для микрософтовских data sources, ODBC абстрагирует кучу разных движков..

http://msdn.microsoft.com/en-us/library/et1kh6d3(v=vs.80).aspx

ЗЫ И вот зачем я это знаю? :))) Под маздай последний раз кодил году в 2000

Да, приходится, просто быстрее и менее болезненно.

В додиезе ODBC вроде как, его же, ЕМНИП

А не ADODB какой-нибудь?

but you can also access ODBC data sources through DAO

О, через него можно и к ODBC достучаться. Все в лучших традициях :)

На самом деле в том что в жабе есть JDBC а в C# тоже какойто аналог (или даже не один?)

Так в пыхе есть PDO, но я выше уже приводил ссылку, почему PDO vs. AnyOtherLanguagesDBInterfaces

И ведь mysqli еще надо поискать, кто использует. А уж, чтобы постгрес + пых - это вообще экзотика, навроде хаскеля.

Все может быть, даже не хочу туда лезть :)

А юникод и строки то нормальные будут или опять нет :-)

одной из причин закрытия 6й версии было то, что они решили, что не смогут в вообразимое время асилить заявленный юникод. Наверняка в пятерке юникода в роадмапе нет вообще.