ну автопрефиксер это да, но для меня лично польза еще для работы с импортами и ссылками на ресурсы типа шрифтов и картинок. Причем не обязательно что-то менять в css, я могу и инфу какую-то выдрать из стилей, аля используемые шрифты и картинки.
С каких пор "пилить на своих наработках и шаблонах" это бэст практис? Бэст практис это например, отделять бизнес логику от фреймворка/библиотек. Либо я не правильно понял вас.
EvgMul: чужой код априори не может быть правильным и красивым. Это я конечно утрирую, но красивый и правильный код вы можете только в книжках найти, в реальности же все обычно куда прозаичнее.
Oleg Shevelev: я отстаиваю идею что "каждой задаче свой инструмент". Для простых задач PHP разработчик может взять то, что ему удобно а именно PHP. Если PHP становится проблемой - то тогда уже можно думать в сторону Go или Rust (Си я принципиально не беру как вариант).
Работа с сетью в PHP не медленная, распаралелить скачивание вы в нем так же можете, все те вещи которые вы используете для этого и так реализованы на Си.
В целом думаю стоит прекратить спор так как он зашел в тупик. Нет пруфов ни моих ни ваших слов, так что...
Oleg Shevelev: без разницы, k-means и на Си медленный.
По поводу задач связанных с данными - согласен, но если обработка данных занимает 10% от времени работы скрипта (90% сьедает работа с сетью) то пофиг на чем писать, и зависеть все будет от того, кому потом придется поддерживать код.
Oleg Shevelev: ну да, для больших объемов я тоже скорее golang возьму, но для задачи автора (разовый парсинг до 10К страниц) и пыха хватит. Всеравно упрусь в I/O а не в производительность языка.
У меня есть задача которую решили на PHP и я сейчас переделываю на Java (банально больше готовых решений под эту конкретную задачу), и там я уперся в алгоритм. Для 5К объектов приходится делать 25 миллионов операций, на сервере задача выполняется за полторы минуты. Но так топорную версию алгоритма реализованную за денек на PHP распаралелить не выйдет - то пофигу. Зато это дало дополнительное время на реализацию более адекватной реализации, которая выполняет то что мне нужно не за N^2 а за N+M, что меня устраивает уже более чем.
Blyyya: для блога документация по PHP норм, можно взять любую книжку, и при упоминании каких-то вещей обращаться к документации что бы сверится. Например если будут ссылаться на mysql_* функции, вы в документации заметите что эти функции устарели и надо использовать PDO или mysqli. В целом же общая картина остается той де. А когда доберетесь до ООП уже можно подключать книжки, причем все самое полезное было написано 20 лет назад.
Blyyya: я могу вам порекомендовать книжки постарше и не по PHP, Кент Бэк, экстримальное программирование, Мартин Фаулер, Рефакторинг. Улучшение существующего кода... ну и т.д.
Valeriy Donika: монга нужна когда вам надо делать агрегации данных. То есть типичный флоу работы с монгой это... храним все данные в реляционной базе, и если мы упираемся в сложные выборки с кучей джойнов - делаем в монге денормализованные агрегации для упрощенных выборок. Если выборки у нас простые - монга не нужна. Ну и еще есть задачи когда надо хранить отдельные независимые документы, у которых может быть совсем не похожая структура - тут монга тоже хорошо подходит. У меня так реализована простенькая CMS-ка где страницы собираются из блоков и каждая страница это отдельный документ.
Oleg Shevelev: а автор что-то говорил про лимиты по памяти? Я что-то не наблюдаю у него таких срок. Заметте, у него каждая страница грузится синхронно, то есть проблема с производительностью. На самом деле для 600 страниц достаточно просто загружать странички по 10 штук за раз и норм.
Повторюсь, я работал с демонами на PHP и проблем с ликами по памятти у меня небыло (точнее было но там дело было в гнилом экстеншене который я потом заменил просто на PHP-библиотеку).
littleguga: можно, только выходит это чуть более чем убого по сравнению с идеей и вовсе забить на префиксы. Что-то сродни автопрефиксера эмулируется миксинами в stylus но это опять же не торт. Ну и опять же - префиксы это весьма простой кейс. А как на счет автоматического преобразования rem в em например (для кросбраузерности) и прочие веселости? Есть масса вещей которые кроме как извратами и миксинами не сделать, и при этом можно просто оставить это дело на пост процессор который сделает все красиво.
не обычная это конкуренция и не использует postcss никаких синтаксисов будущего (не путайте плагин cssnext с самим postcss), sass/less не позволяют производить манипуляций с CSS пользователю, либо позволяют но весьма ограниченно. Подходы абсолютно разные, и никто не запрещает использовать postcss вместе с препроцессорами. Вы же используете autoprefixer?
> GC не удаляет достаточно данных в нужный момент и выделенной скрипту памяти не хватает для работы на длинных дистанциях
нет таких проблем у PHP (насколько я помню из того что я знаю о реализации GC в PHP), он чистит все как только мы потеряли ссылку на объект (когда ref counter == 0).
> Может упасть, а может и не упасть и когда упадёт - заранее не известно.
нужен очень плохой код что бы была такая непредсказуемость.
> Окей, произошло исключение - что делать в таком случае?
почему-то джависты не жалуются что у них надо все что выплевывает исключение оборачивать в try/catch, так же как и любители node.js. Так чем PHP должен отличаться?
> да и оверхед этих исключений приличный.
исключения это ошибка по вине программиста, так что это его проблемы если у него на каждый чих ошибки валятся.
> иногда нужно именно многопоточно
ключевое слово - иногда. При большом количестве потоков мы можем больше времени на переключение контекста сьесть. При маленьком мы получим слабую загрузку CPU так как мы будем не полностью загружать I/O. Оптимальный вариант - event-loop + крутить это в несколько процессов (по процессу на ядро или больше в зависомости от загрузки и задач). Так скажем реализовано во всяких go или erlang-ах. Там микротреды это как раз таки развитией этой идеи, когда выделется оптимальное количество потоков и рамках них идет коорперативная многозадачность. Тогда нет оверхэда на переключение контекста и т.д.
> Я просто не считаю что 1+ гигабайт на файл это много
да я как бы тоже, но чуваку странички нужны, а они уж явно маленькие и там пофигу. Не вижу смысла грузить человека SAX-парсерами. Но в целом да, так было бы лучше и гибше.
> в целом мне ваш ответ понравился:)
мне просто реально интересно как вы видите это все и почему вы считаете что это не работает для PHP)
