PHP (процедурное программирование) vs PHP (ООП) vs Framework

Бросить всё это дело и писать на рубипитоньих фреймворках.

Твое замечание архиважное, ТС явно задумается.

PHP (ФП)

Из перечисленного самое зло — это «голый процедурный подход». Я так писал лет 15 назад (и тоже ратовал за него — типа, скорость, оптимизация, кривое ООП в PHP4 и т.п.)

Прошли первые единицы лет и на поддержке старого кода успел всё проклясть. Перешёл на использование ООП и мало того, что код стал в разы (иногда до 10 раз) меньше в размерах, так ещё и быстрее работать стал. Больше остаётся времени на алгоритмическую, а не копеечную локальную оптимизацию :)

А сегодня если чего-то большого и всеобщего изучать хочется, то не на никому не сдавшийся ZF смотреть нужно, а на Laravel. После него с отрывом — Symfony2, Nette и Yii2:

http://habrahabr.ru/post/254277/

Может стать интересным Lumen, упрощённый Laravel.

Фанатам быстродействия можно смотреть на Pahlcon.

Ну и Slim/Silex для тех, кому хочется всё слепить самому, но на готовых компонентах.

В чём профит ФП на PHP? В нём даже хвостовой вызов не оптимизируется.

В чём профит ФП на PHP?

_Чистое_ ФП на PHP столько мало полезно, как и в любом ином мейнстримовом языке. А вот отдельные элементы... Например, лямбды/замыкания народ начал использовать сразу очень активно и с большой эффективностью.

Замыкания используют часто? Есть же классы, вроде бы все кроме die-hard жабоскриптеров используют больше их.

как сам думаешь?

даже хвостовой вызов не оптимизируется.

есть попытки, в конце концов goto

еще есть лисп на пыхе

Замыкания используют часто? Есть же классы

Очень часто. Во-первых, с момента устаревания ключика /e в preg_replace массово перешли на preg_replace_callback, а в него очень удобно засунуть анонимную функцию. А если эта функция должна работать в контексте исполнения (как раньше с ключиком /e), то нужно замыкание.

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

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

...

Сейчас мельком погрепал — у меня в древнем, 15-летней давности начала разработки ядре фреймворка, уже 12 замыканий, которые вводятся по мере каких-то единичных правок. В основном — preg_replace_callback и array_filter/array_map.

В Composer у меня на типовом проекте, как в коде проекта, так и в зависимых сторонних библиотеках — 188 замыканий.

ФП это не столько рекурсия.

В начале, как выше советовали, посмотри на Laravel или Yii, они гораздо проще будут и для старта должно быть в самый раз.

А ещё я бы подождал ZF3. Вместо него советую пока посмотреть на компоненты Symfony. Не иделал конечно, но сделано достаточно хорошо.

Короче, одним словом, изобретай свои велосипеды (только не надо торопиться делиться ими со всем миром под видом нового конкурентоспособного решения), тыкай фреймворки, читай книжки. И со временем наставником для своего друга будешь ты, если конечно он не хочет всю жизнь лепить говнецо из своих самокатов с квадратными колёсами.

Если тебе не нужно поддерживать код твоего друга, то нафига козе боян?

Laravel попробуй, да и вообще с компонентами symfony познакомься. Если проекты нестандартные то ещё стоит взглянуть на микрофреймворки типа silex. Опять же чтобы хорошо разбираться в выше перечисленном нужно более или менее понимать как компоненты(symfony) взаимодействуют между собой.

Так вот, хочу друга тоже убедить выучить какой-нибудь фреймворк, а он говорит, что это всё зло и пишет сайты процедурным вариантом. Если не сложно и есть время и желание, то выскажите ваше, очень хотелось бы обоснованное, мнение по этому поводу.

Предлагаю забить. Если человек не хочет развития, то для него все потеряно, пусть клепает неподдерживаемый УГ в стиле 90-х. Нормальному разработчику не нужен пинок, чтобы развиваться и эволюционировать.

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

2 чаю сему форумчанину.

Обычно фреймворки позволяют ускорить разработку, т.к. разгружают от рутины, а ООП даёт больше возможностей к улучшению кода. Решение о нужности чего либо принять достаточно просто, есть профит - нужно, нет профита - не нужно. Но от желания и возможности написать какую-нибудь фигню не спасает ни то ни другое.

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