I niech to, że ciężki backend jest dziś „przyjemny”, będzie najlepszym dowodem gdzie to wszystko zabrnęło.

No to ja chyba jakiś dziwny jestem, bo mnie z kolei właśnie jara programowanie w oparciu o interfejsy, wysoki poziom abstrakcji, wyspecjalizowane do maksimum klasy, często z 1 metodą publiczną itp. Po pierwsze i najważniejsze przejście na taki styl pisania dało mi duża frajdę z programowania bo właśnie to "prosto do celu" bardzo mnie męczyło w PHP.
Po drugie wiele razu już zdarzyło mi się, dojść do momentu, gdzie nagle bardzo mocno zmieniały się założenia w jakimś projekcie, spodziewam się, że będzie sporo pracy, otwieram swój kod, a tam jedna klasa do wymiany i bang - działa. Wszystko właśnie dzięki tej abstrakcji i generalizacji.
Czy taki sposób pisania jest szybszy? Sam nie wiem - czasami czuję, że idzie spory overengineering i można byłoby coś napisać odrobinę szybciej, ale z drugiej strony potem mam większą satysfakcję wracając do swojego kodu i mogąc go refaktorować z łatwością.

Ogólnie mi bardzo odpowiada przenoszenie praktyk z Javy do PHP (oczywiście z rozsądkiem) - miałem to szczęście, że ktoś poświęcił mi wiele czasu aby otworzyć mi oczy na to podejście i zrozumieć o co naprawdę chodzi w OOP. Teraz wiele rzeczy jakoś samo mi się w głowie układa i widzę wszelkie zależności, buduje mi się taki big picture z lotu ptaka. W wielu obszarach brakuje mi jeszcze skilii, ale nad tym pracuje. Na przykład ostatnio trochę zerknąłem w testy i próbując napisać trochę testów do swoich starych klas zrozumiałem w praktyce wiele rzeczy, które wkładał mi do głowy mój "mentor", a które trochę olewałem "bo po co tak komplikować".

Druga sprawa to podoba mi się podejście Phpiona (poza tą prostotą i tęsknotą do Kohana ;-) ) i sam chyba też tak trochę mam. Trzeba mieć swoje "core skills", bo one nas żywią, ale warto też robić sporo skoków w bok - a to devops, a to frontend - dobra zajawka na coś jest zawsze na propsie i zapobiega wypaleniu. Ja teraz jestem na takim etapie, że doby mi nie starcza aby liznąć tych wszystkich obszarów, które chciałbym zgłębić.

Nikt tu nie mówił o niechęci do złożonej struktury kodu, chyba że coś przeoczyłem?

No jak tak to odebrałem - np. post Phpiona, czy posty o tęsknocie za starymi, dobrymi czasami. Może faktycznie trochę za dużo między wierszami czytam.

Generalnie dobrze odczytałeś moje intencje. Może nie chodziło mi stricte o Kohanę, ale akurat to był framework na którym pracowałem w tych "lepszych czasach" więc siłą rzeczy skojarzenie jest dość silne. Chodzi mi o to, że wówczas czułem że panuję nad całym projektem. Dołączałem biblioteki PHP jakie chciałem, a nie pierdyliard dodatkowych zależności - i jakoś to działało. Dołączałem jQuery + pluginy, starałem się wszystko trzymać "w jednej kupie". Tak samo style - też jakiś porządek panował. Teraz korzystając z zewnętrznych rozwiązań jest w zasadzie wolna amerykanka. Wspomniałem, że jestem purystą - tak. I duperele mnie drażnią. Pamiętam jak korzystając z PostgreSQL i chcąc dodać nową kolumnę nie było opcji ustalenia jej położenia, a zawsze była dodawana na końcu. Już takie coś mnie drażniło. Kończyło się na tym, że tabelę usuwałem i tworzyłem na nowo w kolejności kolumn jaka mi odpowiadała. Dlatego drażni mnie, że aktualnie wykonuje się 1 polecenie, które zaciąga X pakietów - dla mnie to powoduje burdel. Rzadko również korzystałem z gotowych modułów bo zawsze coś mi nie pasowało. Mam tu na myśli całe moduły (strzelam: do obsługi ankiet), a nie biblioteki (typu generowanie PDF).

Uparłem się na krytykowanie Symfony bo ten framework wiedzie prym i wyznacza aktualne trendy, które mi osobiście nie do końca odpowiadają. Pracowałem na Symfony 1 i przyznam, że całkiem dobrze to wspominam. No może poza generatorem admina, który na pierwszy rzut oka robił wrażenie "wow", ale gdy przyszło do bardziej skomplikowanych spraw to się zaczynały schody. Potem to już zaczęło się dla mnie udziwnianie i przerost formy nad treścią.

Jeśli natomiast chodzi o Kohanę to zawsze będę jej bronił. Ok, może w porównaniu chociażby do ZF1 kod był wręcz laciki, ale kurde działał I nie spotkałem frameworka, który miałby lepiej rozwiązany mechanizm walidacji danych, internacjonalizacji, kaskadowości plików (chyba żaden nie ma takiego jak Kohana - idealny pod SaaS) czy... (czekam na lincz) ORM. Tak, pod kątem ORM moim zdaniem/w moim odczuciu/dla mnie Kohana była wygodniejsza w użyciu niż Doctrine czy inny Propel.

Więc podsumowując: chciałbym by wróciły czasy gdzie więcej spada na barki programisty, a mniej jest magii. Więcej od niego zależy, a nie od tego jakie polecenia wykona.

Przesiądź się na django. Framework odwala za Ciebie nudną robotą, zostawiając Tobie to, co najlepsze - stworzenie logiki aplikacji. Ogólnie odnoszę wrażenie, że PHP na siłę chce być pro/enterprise. Aplikacje/frameworki obudowane są w coraz więcej warstw, jeśli chcesz zrobić coś o czym autor nie pomyślał, musisz przekopać cały projekt.

Kohana była kochana Framework, który można było w kilka wieczorów poznać na wylot, widzieć dokładnie co i jak, gdzie się dzieje. Poprawić po swojemu nie ingerując w core - właśnie dzięki kaskadowości. Ciągle po godzinach rozwijam projekt, który zacząłem w 2011 r jeszcze w Kohana 3.0.9. I o ile teraz programowanie w Symfony mi nie przeszkadza, to jeszcze łapię się na tym, że nie do końca wiem co się stało, jaka magia się odpaliła. Na szczęście obecnie taki PhpStorm świetnie sobie radzi w debugowaniu (nawet szablonów Twiga).

Co by nie mówić, Laravel też jest ko©hany

Tylko rodzi się pytanie, czy my musimy wiedzieć co się dzieje pod maską? Bo w sumie OOP powstało na bazie tego, że programista nie musi wiedzieć co się dzieje tylko ma korzystać z interfejsu i dana rzecz ma działać. Jak nie działa tak jak oczekuje tego programista, to powinny istnieć instrumenty umożliwiające mu zmianę tego działania bez ingerencji w core. Kod jest oczywiście przez to większy i bardziej skomplikowany, ale przypomnijcie sobie ile kiedyś trwało wyklepanie prostego CRUDA, a ile trwa dzisiaj z użyciem Symfony. Ja wiele lat temu bardzo zraziłem się do programowania przez to, że właśnie te trywialne rzeczy zajmowały tyle czasu.

Dzisiejsze programowanie jest na tyle złożone, że nikt tak na prawdę nie wie jak działa wszystko. Mamy teraz czasy osób, które muszą mieć ogólny przegląd pola + specjalizację w jakiejś dziedzinie.

Obecnie pracuję w Magento i bez przesady powiem, że w firmie nie ma ani jednej osoby, która zna ten system/framework na wylot. Myślę, że nawet w samym Adobe nie mają takiej osoby - i mówię tu tylko o części backendowej. Z takim stanem rzeczy się pogodziłem - wystarczy mi świadomość, że mam big picture systemu + jak potrzebuję się czegoś dowiedzieć to mam debugger (bo dokumentacji w przeciwieństwie do Symfony czy Laravela praktycznie nie ma).

PHP dopiero wchodzi w etap kodu enterprise, ale wydaje się (mi), że taka będzie tendencja. Od wersji 7 zaczęły się zmiany w tym kierunku - otrzymaliśmy jeden z najwydajniejszych języków skryptowych z kosmicznie (jak na język skryptowy) rozwiniętymi opcjami OOP, silnym typowaniem, trybem strict, gdyby wersja 8 postanowiła zerwać z kompatybilnością wsteczną w stosunku do części głupich rozwiązań to już w ogóle byłby kosmos.
Język się mocno profesjonalizuje, pojawia się ogromna ilość profesjonalnego kodu, Composer do zarządzania zależnościami itp.

Mini stronki / proste cms'y to już raczej przeszłość. Oczywiście tutaj PHP będzie dalej istniał, bo się do tego zastosowania nadaje, ale też będzie z tego segmentu wypierany przez inne technologie (np. RoR do prototypów aplikacji, Node do prostego backendu, bo wtedy jeden programista ogarnia front i backend itp). PHP moim zdaniem zacznie konkurować z Javą o klienta enterprise. Mnie osobiście to cieszy bo praca ciekawsza i $$$ więcej. Oczywiście nie stanie się to w rok czy dwa, ale taka będzie tendencja -> spadek % udziału w rynku + wzrost udziału w rynku enterprise.

Ogólnie moim zdaniem trzeba się pogodzić z brakiem 100% kontroli, swoją niewiedzą itp i przestawić się na pracę z klockami, ciągłą niepewnością itp. Dokładnie na takiej samej zasadzie jak kiedyś ludzie przechodzili z języków niskopoziomowych na wysokopoziomowe. Oczywiście są też alternatywy - np. nie iść w kod enterprise tylko szukać nisz, gdzie potrzebne jest inne podejście - pytanie jednak czy to będzie php i web ogółem.

Tylko widzisz są tacy zboczeńcy(w tym ja ) którzy powiedzą "o jakie fajne ! A jak to działa ?".
Wiem że to może głupie ale lubię wiedzieć jak działa coś z czego korzystam.
Jasne są takie przypadki jak paypal express, imoje twisto czy logowanie przez fb/gmail gdzie po prostu pobieram i nie pytam co tam się dzieje. Skoro twórcy "zewnętrznych rozwiązań" byli tak mili że coś udostępniają to z tego korzystam zakładając że jest to zrobione dobrze.
Ale jeśli mają to być biblioteki/klasy do robienia cache, routingu, i18n, l10n, obsługi logów czy komunikacją http to lubię tak dla spokojności wiedzieć jak one działają.

To trochę tak jak pracując na froncie(jakkolwiek dziwnie by to nie brzmiało ) zobaczysz coś nowego, fajnego na stronie i pierwsze co robisz to F12.
Ja mam tak samo z php, jak mam z czegoś skorzystać to pierwsze co robię ctrl+click i pokaż kotku co masz w środku.
A gdy już zobaczę i nie do końca rozumiem co się w tym kodzie dzieje to czuję się z tym źle i bardzo niechętnie z tego korzystam.

Jest głupie i pewnie bezsensowne, ale co poradzę że już tak mam

Moim zdaniem to jest jedna z różnic między CMS-em a frameworkiem. W CMS-ach też nie analizuję każdej funkcjonalności, ale już we frameworku owszem. Lubię wiedzieć jak jest zaimplementowana funkcjonalność, na której buduję swój kod. Analiza Laravela sprawia mi też przyjemność, bo nie muszę się łapać za głowę w rozczarowaniu, że coś brzydko zrobiono (a np. z WordPressem tak się często kończyło dłubanie w core).

Ale Panowie oddzielmy kilka spraw. Po pierwsze nie ma nic złego w ciekawości i zajrzeniu jak coś działa, nawet jeśli działa i nie trzeba nic naprawiać. To całkiem zdrowy objaw. Jeśli natomiast ktoś chce mieć 100% wiedzy na temat jak działa wszystko to już nie jest zdrowe, chyba że to praca hobbystyczna a nie zarobkowa. W oprogramowaniu enterprisowym tak się nie da, bo po prostu kodu jest zbyt wiele. Nad tym kodem pracują tysiące ludzi, zmienia się praktycznie każdego dnia - w normalnej pracy klienckiej nie da się nadążać za tymi zmianami, a co dopiero mieć głębokie zrozumienia jak WSZYSTKO działa. Dla przykładu request w trybie developerskim ładuje około ~3.000 klas, drobna zmiana w konfiguracji kontenera dependencji może wywrócić całą tą logikę do góry nogami. Do tego dochodzą jeszcze typy wirtualne, konfiguracja, auto-generowany kod, różnego rodzaju varnishe, rabbity, zewnętrzne integracje, systemy typu mcom itp itd.

Ogólnie moim zdaniem w oprogramowaniu enterprise trzeba się po prostu pogodzić z tym, że odpowiadamy za małą cząstkę kodu - dlatego ten kod jest właśnie tak napisany jak jest - tj. w oparciu o SOLID. Póki działa to możesz go używać. Jak potrzebujesz rozszerzyć to zgodnie z OCP jest to tak zrobione, że możesz go rozszerzyć bez zmiany core itd. Idzie ogromy overengenering, kupa abstrakcji itp itd, ale jak klient chce gruszki na wierzbie, to się pytasz jakie mają być duże (i czy go stać ;-) ).

BTW co do różnicy framework vs CMS to w dużym oprogramowaniu to się zaciera. Na przykład znowu w Magento, które jest przecież CMS'em, masz też framework, który złożonością przypomina Symfony.