×

PHP: піти не можна лишитися. Піти

Image via Shutterstock.

Отже, ви пишете на PHP. Любите жартувати про те, що долари є тільки у вас, при кожній нагоді нагадуєте, що «Facebook написаний на PHP» і стомлено пояснюєте, що сімка — це вже справжня мова програмування. Чесно-чесно.

Проте на будь-які пояснення потрібен час, а випадкові знайомі програмiсти, почувши сумнозвісні три літери, чомусь дуже швидко розчиняються в повітрі. Так само опоненти по онлайн-дискусії, заглянувши на профіль в лінкедіні, кидають «все ясно...» і відповідати чомусь перестають.

Ви прекрасно розумієте, що PHP розвивається чи не найбурхливіше з усіх дорослих технологій, а свої проблеми є у кожного стека (подивіться хоча б на JavaScript!)... Але плисти проти течії важко, і в один момент ви вирішуєте, що все, далі так жити не можна. Пора переходити у «вищу лігу».

Ця стаття має на меті дати вам приблизний огляд альтернативних шляхів розвитку PHP-девелопера. Я впевнений, що тут на DOU є люди, котрі пройшли практично кожен із шляхів, описаних у статті. Запрошую їх до доповнення і заперечення тезисів. Має бути цікаво.

Принцеса Ява, або Святий Ентерпрайз

Якщо говорити про серйозні технології, першою на думку приходить всюдисуща Java. На ній пишуть для великих організацій і банків, програмісти завжди хваляться найбільшими зарплатами, і навіть при тому, що кожного року на ринок висипає нова тисяча джуніорів, потреба в спеціалістах все одно лишається високою. Влаштуватися, як не дивно, вдається практично всім.

Крива розвитку. Всім відомо, що, починаючи з останніх версій п'ятірки, PHP поволі стає на шлях ентерпрайзу, і якщо ви писали на якійсь Симфі чи Ларавелі, об'єктно-орієнтований шлях Джави вас особливо не злякає. Напружувати буде строга типізація всього і всюди, і постійні ексепшни джава-машини, які не зрозуміло, як правильно ловити, і зовсім не ясно, як потім фіксити. Зате явно сподобаються бібліотеки для різних трюків, які мав реалізовувати мертвонароджений Spl.

Після четвертої-п’ятої прочитаної книжки є всі шанси зрозуміти патерни проектування. Заодно, щоправда, зрозуміти і те, що вони нікому не здалися. Але це вже зовсім інша історія.

Переваги. Хороший Java-програміст ніколи не залишиться без роботи. Достатньо висунути з вікна резюме, і на нього відразу злетиться ціла юрба молоденьких рекрутерок, готових на все заради підписання контракту. Робота, зазвичай, стабільна і з хорошими бонусами. Компанія буде робити все можливе, щоб втримати вас на місці, в тому числі, і в зарплатному сенсі. Можна купити більше сиру і лінз до зеркалки. Ляпота.

Недоліки. На відміну від вебу, фріланс-роботу на Джаві знайти доволі непросто. Доведеться йти в якусь контору, причому бажано на повний робочий день. З огляду на те, що джуніорів на нормальні проекти ніхто брати не хоче, рік-два доведеться потерпіти в якісь шарашці, зі значним пониженням грейду.

Ще вам, швидше за все, доведеться забути про всілякого роду стартапи. Системи, які ви будете розробляти, будуть складними, стабільними і, здебільшого, шалено нудними. Написавши за рік-два готовий проект, готуйтеся до десятирічного сапорту. Життя довге і, кажуть, до пенсії можна встигнути викотити соту, ювілейну версію софту для автомату з продажу кави. Яке-не-яке досягнення.

«Блаженні вбогі духом», або empty-stack developer

Східні філософії кажуть, що для того, щоб пізнати нірвану, треба спочатку відмовитися від усіх земних амбіцій. Перехід з PHP на JavaScript — дія того самого розряду, адже джаваскриптери — це чи не єдині, кого лишається зневажати пехопешникам. Часто єдина думка, що могла зігріти довгими ночами дебагу, була про те, що «в Джаваскрипті все ще гірше». І це, якщо чесно, і справді так.

JavaScript ніколи не планувалося робити серйозною мовою. Його творець признавався, що написав його за десять днів, і сам здивувався раптовій популярності свого дітища. З того часу всі, кому не лінь, намагаються перетворити JavaScript в нормальну мову, але виходить якась незрозуміла муть. Тим не менше, якщо ви прийшли в PHP з боку фронтенду, повернення в рідні пенати може навіть викликати у вас приємну ностальгію.

Крива вивчення. Якщо ви колись писали кілька рядків на jQuery, базу ви вже знаєте. Стосовно глибоких знань... Існують дослідження про те, що в мозку є спеціальний відділ для розуміння базових принципів JavaScript. Він дістався нам напряму від рептилій і ні в вербальну, ні в навіть графічну форму, це знання не конвертується. Допоможе тільки досвід: кров і піт, нецензурна лайка і розбиті об голову клавіатури. Якщо стане зовсім туго, можна згадати, що основним суперником JavaScript був VBScript. Тобто, могло бути і гірше.

Переваги. Нода, незважаючи на недавні фейли, показує достатньо непогані результати і погрожує забрати у PHP серйозний шмат ринку. Враховуючи, що з боку фронтенду впевнено наїжджають всілякі Ангуляри, а HTML5 дає можливості портувати DOOM, Джаваскрипт може серйозно розширити свою нішу «динамічних формочок» до «всього, що відбувається в вебі», і пропустити цей поїзд було б як мінімум необачно.

Недоліки. Клеймо фронтендера може бути навіть неприємнішим за титул PHP-програміста, і вас постійно будуть просити наверстати шаблон або підправити лого в фотошопі. Можливо навіть частіше, ніж написати код чи спроектувати архітектуру. Якщо CSS і pixel-perfect — це не ваше, в JavaScript краще не потикатися. Я серйозно.

Програмування заднього кінця, або скалабіліті убер алєс

Якщо ви доста непогано розібралися в архітектурі, знаєте чим GET відрізняється від HEAD, а latency від bandwidth, є сенс подивитися на інші серверні стеки. Найсильнішими гравцями на даний момент є Scala і Go. З огляду на те, що в першій не продихнути від колишніх джавістів, і вакансії зазвичай подвійні (Java/Scala), переходити з PHP на Scala видається не найкращим варіантом. Проте Go з цієї точки зору — просто казка.

Крива вивчення. Скажу чесно — щось із ваших знань вам таки знадобиться. Частково. Наприклад, оператор if. А ще функції є і там, і там. Якщо починати копати глибше, мозок доведеться трохи переламати.

Перехід до функціональності замість ітеративності в Scala і надмірна, я б навіть сказав «агресивна», простота Go даються на початках нелегко. Чого тільки варта відсутність опціональних параметрів або неявні інтерфейси.

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

Переваги. Враховуючи, що технології доста нові, десятирічних сіньйорів, як в Джаві, тут не водиться. Вакансії на сіньйорів зазвичай містять пункти «5 років досвіду в програмуванні» і «at least one project on Go (commercial or personal)». Це означає, що погравшись на гітхабі з якоюсь бібліотечкою, спокійно можна переходити в новий стек без пониження грейду і тайтлу. Справжнім сіньйором ви відразу не станете, але де вони є, ті сіньйори Go? В гуглі?

Недоліки. Молоді, трендові технології мають властивість час від часу здуватися з голосним пшиком. І якщо PHP найближчі років десять точно ніщо не загрожує, тренди, що стали модними занадто швидко, так само швидко можуть цього статусу позбутися. До того ж, унаслідок своєї молодості, ці стеки часто не мають всієї необхідної інфраструктури, якою може похвалитися PHP. Спитайте гоферів, як вони дебажать. Сміятися краще не треба — поб'ють.

Parseltongue програмування, або де мої дужки, прінт?

Пітон, по суті своїй, завжди сприймався як простенька мова, без особливих можливостей. Щось подібне до Паскаля: так, повчити діток програмування.

Але Youtube, Reddit, Instagram і Uber недвозначно довели, що великі проекти на ньому писати можна і треба. Девелопери Реддіту розповідали, як переписали весь код на Пітоні за один тиждень, причому 80% проекту було написано за вікенд.

Простоту оцінили і вчені. Стільки наукових бібліотек, як на Пітоні, нема в жодній мові. Тому якщо ви збираєтеся заглибитися в машинне навчання — особливих альтернатив у вас практично нема. Ну, хіба ще Lua, але екзотику ми зачепимо трохи пізніше.

Підходить Пітон і для вебу. Якщо перше, про що ви подумали після цієї репліки, було Django, раджу краще подивитися в бік Flask. Мені особисто він видається простішим і стабільнішим.

Крива вивчення. Ви вже знаєте Пітон. Ви просто про це не підозрюєте. Базові речі піднімаються за два дні, а тиждень вправ на leetcode додасть усе інше. Звісно ж, читаючи серйозний проект, ви час від часу натикатиметеся на дивні речі, яких ніколи не бачили, але документація і стек оверфлоу дадуть відповіді в два кліки. Словом, ви вже знаєте пітон. Чесно.

Переваги. Вам буде набагато простіше дихати без усіх цих фабрик сінглтонів та іншої лабуди. Ви навчитеся кожну думку виражати максимально чітко і просто, без генераторів коду і нашарувань безглуздих патернів проектування. У вас буде шанс потрапити на цікаві, наукомісткі проекти і навіть час від часу робити світ кращим (привіт, наприклад, NASA або CERN). Тому, якщо у вас лишився незакритий гештальт з університету — саме час пригадати усі ті персептрони і мурашині алгоритми, про які ви крізь сон чули щось із останніх рядів аудиторії. Плюс тисяча до самооцінки, до речі.

Недоліки. Кожне спрощення має свою ціну. Відсутність нормального ООП з усіма його заморочками може деколи серйозно напружувати. Динамічна типізація теж не грає на руку стабільності, і баг часом доводиться ловити довго і нудно. Але до цього ви вже в PHP звикли, чи не так?

Незважаючи на успіх гігантів, нових проектів на Пітоні не так вже й багато. Стартап радше вибере PHP або Рельси, ентерпрайз подивиться в бік Джави або Плюсів, і в один момент ви можете опинитися в ситуації, коли вакансій, по великому рахунку, не так вже й багато. Зарплата за межами топів теж особливо не вирізняється: за PHP в середньому вища, але явно не настільки, як в Джаві.

Ну і звісно без пониження грейду перейти на сіньйора буде важко. А враховуючи, що на всіх курсах «Вайті в айті» починають тепер з Пітона — можуть виникнути проблеми і з мідл вакансіями. Якщо вибрали цю дорогу, ґав ловити вже не вийде.

Дорогоцінні камені, перетворені на пісок

У свій час Ruby завдяки рельсам стала чи не найпопулярнішим вибором для стартапів. Приголомшливий успіх пригнав у технологію купу народу, більшість із них там і залишилася, навіть після карколомного падіння. Сапортять той один відсоток стартапів, що вижили, і час від часу намагаються прорватися в Твітер, який повільно, але впевнено перековбашує свій монорельс на JVM.

В цьому розділі я не буду писати багато, бо мій досвід з Ruby закінчився багато років тому на спробі пофіксити плагін для Redmine. З того часу я не дуже прихильно до нього ставлюся, тому, якщо хтось може поділитися досвідом і підводними каменями переходу, буду дуже вдячний.

Мертві страуси і хардкор

С++ недавно випустив чергове оновлення. Тепер базової документації стало повноцінних півтори тисячі сторінок. Якщо запитати хардкорних плюсовиків, які можуть бути проблеми у переході з PHP, вони будуть довго сміятися. А потім, якщо не надірвуться, порадять ніколи і ні при яких обставинах туди не соватися. І будуть в цьому абсолютно праві.

Крива вивчення. Навряд, чи я можу сказати тут щось осмислене, адже в мене все відбувалося у зворотному порядку: коли мене стомили постійні проблеми з пам'яттю і абсолютно неочевидна поведінка стандартних бібліотек, коли я задовбався 90% часу виділяти на дебаг типів даних замість реалізації бізнес логіки, я плюнув і пішов ваяти сайти по сто баксів за штуку і без проблем для нервової системи.

Тому занурення в плюси людини, яка вміє писати тільки на PHP, я уявляю собі слабко. Напевне, це буде схоже на кошмар. Або на розмову китайця з угорцем без перекладача. Покивають і розійдуться, без особливої шкоди одне для одного.

Переваги. Плюси — це круто. На плюсах можна писати ігри, браузери і навіть операційні системи. Якщо ти пишеш на плюсах, ти можеш спокійно перейти на будь-що інше, окрім, напевне, Асемблера. Хоча і на Асемблер, напевне теж. Адже без його вставок навряд чи вийде написати щось справді хардкорне. На плюсах пишеться саме серце сучасної технології. Я б навіть сказав — її душа.

Ще ви зможете писати код для всілякого роду девайсів і роботів, і коли скайнет поневолить людство, десь там між бібліотеками може навіть знайтися кілька ваших стрічок рядків коду!

Недоліки. Внаслідок абсолютно ідіотського рішення вивчати програмування в університетах на прикладі плюсів, С++ джуніор — це ягода того самого поля, що і джуніор Java. Проштовхнутися між ними буде доста важко. Досвід з PHP перевагою тут зовсім не буде, радше навпаки.

Також є великий шанс потрапити на «мегацікавий» проект в стилі написання і підтримки кодеків до відеоплеєра. Цікаво перший місяць, а далі починається смертна нудьга і постійне копання в перевантаженій технічними даними документації. Словом, задоволення на любителя. Але, якщо любитель саме ви — вперед!

Яблука, роботи і розбиті вікна

Бум мобільних девайсів спричинив різке зростання потреб у мобільних девелоперах. Бульбашка доткомів переросла у бульбашку додатків (не можу примусити себе сказати «застосунків»), і остання лопатися поки не збирається. Можна встигнути застрибнути на поїзд, котрий рухається, або в прірву, або в щасливе майбутнє. Як пощастить.

Крива вивчення. Андроїд пишеться на Джаві, тож зауваження ті самі, що і в першому розділі. На Обжектіві я писав мало, тому більше чекаю на ваші коментарі, але суб'єктивне відчуття мені нашіптує, що розібратися з ним повинно бути теж неважко. До того ж, завжди є всілякого роду фонегапи, де можна наваяти усе на Джаваскрипті і зробити вигляд, що так і має бути. Перспектива таких підходів, тим не менше, — достатньо сумнівна.

Переваги. Кількість смартфонів на землі зростає з шаленою швидкістю, і комунікують із сервісами вони в основному через додатки. Без роботи ви явно не залишитесь. Почати писати код можна і самому: ліцензія розробника під iOS коштує сто баксів на рік, а у випадку з Android достатньо взагалі одного девайсу. Склепаний за кілька десятків вечорів черговий трекер фінансів може послужити вам непоганим портфоліо, і на роботу можна йти уже впевненим мідлом, на зарплату пехопешного сіньйора.

Це якщо хочеться йти на роботу. Мобільна розробка — це одна з небагатьох ніш, де програміст може досі заробити гроші напряму в користувачів і навіть має шанс на шалені прибутки у випадку аномалій на кшталт Флапі Бьорд.

Недоліки. Ніша, якою б вона широкою не була, лишається все ж нішею. Будь-які сподвижки в розробці мобільних сайтів можуть дуже швидко урізати ринок як мінімум вдвоє. Популярність платформи теж не вічна — подивіться, що сталося з віндофонами.

Разом з тим основний функціонал вашої системи все одно буде лежати на сервері, і вам доведеться або розбиратися і з ним теж, або надіятися на адекватність колег. Враховуючи наївність другого підходу, вивчення хорошого бекендового стека явно не завадить. Але з іншого боку, ви вже знаєте PHP!

Шаманські наспіви серверних

Посада DevOps — достатньо новий винахід. Якщо коротко, це щось середнє між сисадміном і розробником інфраструктури. В стилі: «Я не програміст, але якщо не можу знайти потрібного софту, я його просто пишу». Якщо ви приділяли достатньо часу деплою вашого PHP проекту, і вам це сподобалось, ця дорога — для вас.

Крива вивчення. Вік живи, вік учись. Інакше ніяк. Технології тут застарівають навіть швидше, ніж у всіх інших сферах, тож ніс по вітру доведеться тримати постійно. Вмієте задокерити проект і налаштувати папети на вагранті — цього буде достатньо для початку. Далі — rtfm. Проте, перед тим, як починати, навчитися виходити з vim усе ж доведеться.

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

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

Недоліки. Почати напевне варто з того, що девопсів програмістами вважають не тільки лиш всі. Точніше мало хто так вважає. Набагато частіше доводиться носити ярлик сисадміна і перевстановлювальника вінди для бухгалтерії. Є ймовірність, що доведеться таскати серверні стійки на дев'ятий поверх. Добре, якщо вони влазять у ліфт. А якщо ні?

Відповідальність за стабільність системи тепер повністю на ваших плечах. Чекайте дзвінків посеред ночі, на вихідних і посеред відпустки. Стабільна робота всіх систем, натомість, ніяких бонусів не принесе. До хорошого звикають швидко.

Вкладка «інше», або ранні послідовники

Найпростіший спосіб добитися успіху в певній сфері — почати цікавитися нею з самого початку. Кожного місяця у світі народжується щось нове, і невелика кількість цих немовлят в недалекому майбутньому ввірвуться на ринок, розмітаючи конкурентів, як ангуляр з реактом винесли усі джаваскриптові фреймворки.

Більше того, технології можуть набути популярності навіть після десятиліть тихого існування на задвірках айті світу. Тому, якщо ви обожнюєте Lua чи Rust, чи Kotlin, або фанатієте від Хаскеля з Кложурою, не спішіть зраджувати собі, переходячи на щось модне. На вашій вулиці теж може бути свято. Світ міняється дуже швидко, хто був нічим, стане всім. Ну і, звісно навпаки.

Звісно ж, я пропустив багато інших технологій і напрямків, у які ще можна податися. Наприклад, як ви помітили, я не сказав зовсім нічого про С чи С#. Справа у тому, що я намагався писати тільки про те, з чим стикався хоча б побіжно (про С в контексті написання модулів для PHP я розповім у наступній статті). А все інше — доповните ви в коментарях. Всі ж тут вірять в опен-сорс, чи не так? :)

Замість висновків

Філологи кажуть, що для того, щоб справді зрозуміти рідну мову, треба вивчити одну-дві іноземних. Це прекрасно працює і для мов програмування. Перестаючи сприймати кожен концепт вашого улюбленого стеку, як даність, починаєш відразу розуміти глибинну суть базових принципів, і, як наслідок, починаєш писати кращий код. Тому спробувати нове варто навіть тим, хто переходити нікуди не збирається. Зайвим не буде точно!

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

Не перемикайтесь!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному3
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Чувак, пиши ще!
Дякую за статтю. Давно не читав нічого настільки хорошого, написаного живою українською. :)
P.S. Ображені товариші по цеху (PHPшники) — шо ви зразу в «стойку захисту» стаєте і роказуєте про те шо PHP найкращий і нікуди не тре йти.
Стаття повна сарказму(сатири) і мені здається трохи не про те що PHP поганий, а про особливості життя на інших планетах :)
P.P.S. Якщо я правильно прочитав, то автор нікуди не пішов і далі пише код на PHP

Існують дослідження про те, що в мозку є спеціальний відділ для розуміння базових принципів JavaScript. Він дістався нам напряму від рептилій і ні в вербальну, ні в навіть графічну форму, це знання не конвертується.

это прекрасно!!

Надо было жестче, чтобы у людей, которые только посматривают на IT или учатся, сразу отбивало желание кодить на PHP. Серьезно, вы делаете хорошее дело — становится гораздо свободнее дышать в поисках работы. Так что да — да, пхп — несерьезно, низшая лига, при виде разработчика на пхп сразу отворачивает.... Пишите еще :)

На доу зявились автори яких любо прочитати. Вітаю.

Че на автора так накинулись? Написано с юмором, мне понравилось. Хоть к пхп вообще отношения не имею.

197 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Дякую вам авторе! Дуже приємно почитати таку високообразну статтю по мотивам IT. Я насолодився живою українською мовою в розрізі професії, пишіть щє! Та як на мене тайтл статті та головна картинка занатто сумні. PHP rocks і все ще міцний середнячок у всіх відношеннях.

Коментар порушує правила спільноти і видалений модераторами.

Статья прекрасна даже не с точки зрения полезности советов по теме «куда податься бедному пхп-шнику», а как обзорная карта ныне происходящих движений в it-индустрии. Очень хорошо, автору респект.

Продовження:

PHP: піти не можна лишитися. Лишитися
dou.ua/...articles/php-improvement

Ви вже знаєте Пітон
,
Відсутність нормального ООП з усіма його заморочками
, — я так підозрюю автор пайтон вчив з вікіпедії.
сисадміном і розробником інфраструктури.
- на якій фірмі працюють такі DevOps? Напишіть щоб люди знали кого оминати десятою дорогою.
Світ міняється дуже швидко, хто був нічим, стане всім. Ну і, звісно навпаки.
— це певно стосуєтся невдах які крім пехапе нічого не бачили.

Стиль тексту крутий. Гумор присутній. Зміст слабенький.

випадкові знайомі програмiсти, почувши сумнозвісні три літери, чомусь дуже швидко розчиняються в повітрі

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

Дуже гарна стаття, чекаю на продовження, дякую)))

Вобще прикольный тролинг

Хороший Java-програміст ніколи не залишиться без роботи.
Пора переходити у “вищу лігу”.
— только любой хороший програмист без работы не останется:), сложность задач от языка особо не зависит, ну и главное — переход на другой язык не делает из плохого программиста хорошего:)
любой хороший програмист без работы не останется
Це якщо в блекліст не потрапить ;)

Чтобы во все блеклисты попасть, это надо постараться:). Но если нужно, то блеклист всегда можно выкинуть.

Попадись мне эта статья года 3 назад, может быть, так бы и не остался в PHP.

В то время я месяц метался между Python, Ruby и Node.js: на Python писал один знакомый, пересев на него с PHP; коллега в свободное время прошел онлайн курс по Ruby в Стенфорде и в перерывах нахваливал его. Node.js привлекал как возможность писать на знакомом JS, но серверные приложения.

Но как-то понял: а ведь есть много чего не испробованного в PHP. И тут понеслась: пощупал тесты на Zend Certified Engineer, пощупал SPL (не знаю, почему автор считает его мертворожденным), воркеры и прочие модные слова.

IMHO, если вам «жмет» язык программирования, нужно выйти из Матрицы и посмотреть на себя: а все ли я испробовал/знаю в этом ЯП? А может сертификацию пройти?

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

А то вариться в паре-тройке проектов на вездесущих Symfony/Zend/Yii/Laravel — это немного не то развитие. И, как кто-то уже упоминал ниже, лычка «Senior» получается не столько за достижения, а за «отмотанный срок» на проектах.

Автору респект, интересно было читать статью.
Сам некоторое время писал на PHP в основном фриланс и багфикс на текущей работе (по обязанностям что то около DevOps). После того как пощупал Python писать на PHP немного перехотелось, сейчас штудирую Python все свободное время.
Пугает количество вакансий и требования, Джуном устроится похоже не реально.
Буду рад если кто-то поделится своим опытом перехода на Python.
Сейчас начал писать свой социально полезный проект на Django, а вдруг выстрелит:).

Хорошо пишите, спасибо за статью!
Жалко нету C# хотелось бы побольше эпичных фраз в его сторону)

P.S.: Cтатья полезна и всем языкам из списка в случае начала поиска себя в рамках перечисленных в статье же минусов)

Перейшов з пихи на пітон — дуже щасливий вже 2 роки.

А до цього був нещасний і пригнічений?

На доу зявились автори яких любо прочитати. Вітаю.

Дякую за статтю

Господь, ты ли это? Только вчера думал ровно о том же, что написано в статье.

Пару моих копеек за Джаву:

є всі шанси зрозуміти патерни проектування. Заодно, щоправда, зрозуміти і те, що вони нікому не здалися.
Мне понравилось как Владимир Кочетков в докладе Философия Application Security сказал что патерны это “образцы” которые нужно уметь распознавать а не “шаблоны ” по которым делать.
Проблема в том что в Джаве принудительное ООП при довольно ограниченном синтаксически языке и и всё время приходилось думать как его же блин написать и куда запихнуть класс. хотя Но постепенно язык обогатили и те же лямбды теперь теперь заменяют половину патернов от стратеги до бидера.
ексепшни джава-машини, які не зрозуміло, як правильно ловити, і зовсім не ясно, як потім фіксити.
Экспешены самой джава машины на практике это только OutOfMemory, но в целом как ловить и обрабатывать ошибки это до сих пор больная тема во всех платформах у которой единственно правильного решения пока окончательно не выработали. Из моего опыта обрабатывать ошибки в ПХП сложнее, просто сложность изначально скрыта.
На відміну від вебу, фріланс-роботу на Джаві знайти доволі непросто. Доведеться йти в якусь контору, причому бажано на повний робочий день
О, это это печаль, да. Основной софт на джаве — банковско-энтерпрайзный а даже если и нет то всё равно пишется командой. И людям с улицы не доверяют, хотят видеть. С фрилансом очень туго, но удалённую работу найти реально. Я когда я захотел устроится на серьёзный и большой проект пришлось устраиваться обратно в офис.
. Хороший Java-програміст ніколи не залишиться без роботи.
Ну я бы отметил что тут ключевое именно хороший. Тут фишка в том что на Джаве очень много легаси проектов которые выжили и проносят деньги, но работать с ними требует огромной экспертизы и профессионализма. Ну и свободы творчества не так много.
Поэтому по своему опыту быть джуном и мидлом на джаве это очень уныло. Но если сможешь дорасти до синьора то получишь больше возможностей и интереса.
И множество проектов на которых джунор просто не справится а скорее даже навредит. Поэтому в джаве всем нужны сразу синьоры, и найти их не так просто, более того, их, настоящих не так уже и много.

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

Спасибо за статью, хорошо написана

Мне кажется, если хочется

свободы творчества
то можно пробовать андройд.
андройд

Мейні зайвжди буйло ційкаво чойму дейякі люйди пийшуть слойво «андроїд» зй лійтерою «й».

Поєднання «і» з голосними погано лягає на слов’янську вимову, тому «і» біля голосних транслітерується в українській мові транслітерується в «ї».

А в бідних росіян «ї» нема, а вимовляти все одно незручно, тому викручуються, як можуть.

С фрилансом очень туго, ... Я когда я захотел устроится на серьёзный и большой проект пришлось устраиваться обратно в офис. по своему опыту быть джуном и мидлом на джаве это очень уныло.
именно. вот поэтому я ушел из джавы. на — php :)
серьезные проекты на пыхе все равно ООПшные, и с циклом разработки, все больше похожим на правильный.
а с мелких проектиков — быстрая отдача в виде морального удовлетворения. :)

да и сама Java... я ждал что Groovy взлетит. а когда понял что не взлетит, то ну ее.

на Джаве очень много легаси проектов которые выжили и проносят деньги
именно. и что интересно — легаси на пыхе еще бОльший ...ц, но — и возможности переписать шансов больше.
Є ймовірність, що доведеться таскати серверні стійки на дев’ятий поверх. Добре, якщо вони влазять у ліфт. А якщо ні?
так это же девопс! нужно накодить свой лифт!

Девопс? Накодити? Ні! Девопс це зібрати із сорсів. Бажано в новому будинку.

Пітон, по суті своїй, завжди сприймався як простенька мова, без особливих можливостей. Щось подібне до Паскаля

Потім такі і пишуть ідіоматичний паскалівський код на пітоні... Трохи недооцінений пітон, як на мене, але місця для суб’єктивізму на просторах та поза межами доу вистачить всім.

постійні ексепшни джава-машини, які не зрозуміло, як правильно ловити, і зовсім не ясно, як потім фіксити

Ось це також дивує :/

Хорошая статья, но

і вас постійно будуть просити наверстати шаблон або підправити лого в фотошопі
Неужели так мало мест, где верстальщики — отдельно, джеесеры — отдельно?

в вебстудиях это всегда один человек

вроде бы и просто, но читается сложно

Ви самі собі суперечите:

Якщо ти пишеш на плюсах, ти можеш спокійно перейти на будь-що інше
 — так і Амінь.
Внаслідок абсолютно ідіотського рішення вивчати програмування в університетах на прикладі плюсів
 — рішення зовсім не ідіотське, дивіться попередню цитату.

Тільки ж хотів написати точно такий самий коментар.
Насправді, ідіотським рішенням є вивчати паскаль на перших курсах.
Паскаль/пітон можна вивчати в школі.
В ВУЗі — лише плюси (ну ... і якась функціональщина), а решту мов викладати треба не більш ніж пару-дві .... по ним достатньо лиш давати завдання :)

Правда, є ще всякі design patterns, особливості JVM чи операційних систем, тощо. Але тут вже мова програмування є лише інструментом, який і так всі знають і є сенс абстрагуватися від нього (тут java, там C++, а в python-і сяк).

Ну дивіться: після того, як ти навчився поратися із фурою, легкова машина тобі теж підкориться доста легко. Але це не означає, що потрібно вчити водіння, починаючи з вантажівок.

С++ попри всі свої переваги має два суттєвих недоліки. По-перше, вона складна навіть для простих проектів. Постійна боротьба з сегментейшн фолтами, показникова арифметика, меморі ліки, і все в такому роді, що відбиває бажання розбиратися з програмуванням узагалі.

По-друге, навіть опанувавши мову на початковому рівні, неможливо написати більш-менш корисний проект. Раніше писали на Білдері, але це мрак і первісний жах. Студія з її формочками теж нічим не краща. Більшість часу йде на боротьбу з пам’яттю, ніж на бізнес логіку.

Відповідно багато з тих, хто могли б кодити, здаються і не програмують взагалі. Натомість на пітоні чи пехопе можна відразу підняти проект і навіть при певному везінні отримати за нього гроші. На Джаві відразу можна накатати аппу для андроїда, або простенький десктопний проектик. Та що там, навіть на джаваскрипті з ангуляром можна відразу брати і кодити. А на сях — ні.

Ви звісно можете заперечити, що тим всім, хто не осягнув магію плюсів — не місце в айті, і в чомусь будете праві. Але з іншого боку, якщо програмування — не основне твоє заняття, а ти, наприклад, аналітик, чи вчений, чи страхувальник чи навіть тестер, основи програмування тобі знати дуже і дуже бажано. А плюси — не потрібні в принципі. Якось так...

хто не осягнув магію плюсів — не місце в айті
Саме так. З тих, хто не осягнув магію C, зазвичай, получаються гавнокодери, які створюють месенджер для телефона на 200 Мб.
І так, якщо програмування не основне ваше заняття, то без C зможете обійтися.
Якщо основне — то й Ассемблер, і навіть машинні коди і програмування мікроконтролерів не завадять.
По аналогії з автомобілем: щоб їздити вистачить навчитися керувати автоматом, а щоб бути профі, мусиш володіти ручною коробкою і розуміти як автомобіль влаштований.

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

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

Я просто бачу вчених-математиків, яким би явно не завадило пописати програмки для їхніх задач, але вони кривляться, бо в універі були плюси, а це жах, і вуаля, за межі матлабу виходять не тільки лиш всі.

А месенджер на 200 мб це в більшості загрузка нафіг не потрібних бібліотек. І ні від мови і від освоєння плюсів це залежить дуже мало.

А месенджер на 200 мб це в більшості загрузка нафіг не потрібних бібліотек. І ні від мови і від освоєння плюсів це залежить дуже мало.
Якщо програміст у свій час вивчав плюси, то він, принаймі, знає, що таке пам’ять і як вона використовується. В кращому випадку знає і що таке API операційної системи, і що замість використання бібліотеки на десятки мегабайт можна напряму звернутися до цього API.
Аналогія з JS — коли лише заради звернення до елементу по його ID підключають цілий фреймворк замість того, щоб написати getElementById

Що до не професіоналів, ви праві — їм C не потрібен.

P.S. Якщо ще не здогадалися, меседжер, про який йде мова — Skype.

ох.
хоча це був лише приклад, проте показово:

.Аналогія з JS — коли лише заради звернення до елементу по його ID підключають цілий фреймворк замість того, щоб написати getElementById
а справжні критичні втрати по пам’яти будуть не через це, а через абсолютно інші участки, пов’язані з логікою роботи гарбадж колектора.
тож виходить, що «базові знання» не лише не допоможуть, а й можуть привести на хибний шлях самовпевненності «зараз виріжу цю зайву змінну, та у нас споживання пам’яті впаде»

P.P.S Я не закликаю все писати на С (ми б досягли значно більшого, але в нас немає стільки часу і програмістів). Лише до розуміння того, що насправді відбувається під час виконання програми. С — хороший засіб для цього.
Сам я зараз пишу на PHP, але маю в багажі: C/С++, асемблер, машинні коди, ази програмування мікроконтролерів і проектування елементів процессора — все це дає розуміння того, що стоїть за моїм кодом на PHP.

Я с вами согласен что это всё не упало математикам, аналистам и тестировщикам (вынесем за скобки тот момент что у математиков ничего и нету кроме фортрана, сей и матлаба, а с мехматов порой больше квалифицированных программистов выходит чем с CS). Но вообще говоря мне плевать какие там у них инструменты, я программист, вы программист, и речь в статье идёт о программистах. Ну так вот, ИМХО для программистов учить Си (не обязательно с плюсами) нужно в обязательном порядке. Почему? На этот вопрос отлично отвечает автор одной из моих любимых статей:


И тут вы спросите: «Почему кто‐то станет писать на гротескном языке, поддерживающем прямую работу с памятью? Почему не использовать современный язык со сборщиком мусора, функциональными примочками и бесплатным массажем после обеда?» Я вам отвечу: указатели реальны. Железо только их и понимает, и кому‐то придется иметь с ними дело.
На мой взгляд, обучать программированию нужно в таком порядке:
1. Вначале учимся на каком-нибудь языке писать какие-то сравнительно несложные, но заставляющие много думать вещи, чтобы развить логику, умение мыслить и решать задачи. Язык — не Си, а какой-нибудь более простой (тот же Паскаль, пофиг, можно Go или какой-нибудь скриптовый язык, нам важно научиться программировать в принципе и возбудить в себе азарт к этому).
2. Теперь учимся писать на Си, желательно какие-то вещи где надо много работать с памятью и системными вещами, параллельно с этим учим архитектуру компьютеров, операционных систем и возможно также программирование под микроконтроллеры. Здесь же учим алгоритмы и структуры данных и реализуем их на Си (с плюсами или без, по желанию).
3. И наконец, с этим багажом учим Java или C#. Продолжая автомобильные метафоры, это должно быть примерно как пересесть с ручки на автомат. Вы уже умеете программировать, и здесь вы учите паттерны проектирования, SOLID и прочую энтерпрайзную муть.
Постійна боротьба з сегментейшн фолтами, показникова арифметика, меморі ліки, і все в такому роді, що відбиває бажання розбиратися з програмуванням узагалі.
А навіщо з ними боротись, якщо їх можна уникати? RAII, smart pointers — вот ето вот всьо — купа ліб, які підставлять тобі плече.
Раніше писали на Білдері, але це мрак і первісний жах.
Ти точно писав на білдері? Білдер якраз тим і хороший був, що він мав плюшки з 2 світів: якісний делфячий VCL і C++ -ні ліби — STL, Boost, купа самописних і третьосторонніх.

При чому, проявивши невелику ловкость рук, ці речі прекрасно змішувались. Начитався Александреску, накрутив свій клас смарт поінтера і пхай його у всі місця.

Так, Білдер не безгрішний: своєрідна (не-)підтримка стандартів, глюки в куточках, куди мало заглядають, неясне майбутнє і зав’язка на дураків маркетологів у Борланді. Але тим не менше, первісним жахом він не був.

Напружувати буде строга типізація всього і всюди,
а мене навпаки напружує динамічна типізація :)

та це взагалі щось страшне! Людям, котрі лобують динамічну типізацію, вже зарезерване місце десь там поруч з тими, хто запропонував «null».

які у вас проблеми з NULL?
типу такого: habrahabr.ru/post/165021 ?

найс, дякую.
проте не згоден, що це таке вже зло.
насправді, розробка/розвиток мови програмування має спільні риси з розвитком програмного(або навіть і ні) продукту.
наприклад, деякі рішення виявляються невдалими. через деякий час.
окрім NULL сходу можу назвати декілька різних форм інкріменту(++) та таймзони.

насправді, розробка/розвиток мови програмування має спільні риси з розвитком програмного(або навіть і ні) продукту

Влучно, створюється проблема, а потім вже міріади шляхів її вирішення.

не згоден.
ніхто не створює собі та іншим проблему навмисне.
просто якась частина рішень є більш вдалою і створю проблем менше, ніж вирішує; а якась частина — навпаки. а ще є деякий сет «збалансованих» — з якими треба бути обережним, і тоді можна уникнути пострілу в ногу.

c’est la vie

[UPD] можна погуглити щось на зразок «невдавлі рішення вело», чи те ж саме про авто. буває, невдале рішення ще довго агонізую, поки піде з ринку

Типізація — справа звички, null — необхідне зло. А от тим, хто вертає false, коли не може повернути стрічку, я би багато чого висловив :)

дуже файно дин. типізація у цьому випадку підійшла б :D

null — необхідне зло
Можна дуже просто обійтись без null, користуючи алгебраїчні типи даних.

:)))
поясність, будь ласка, на прикладі з будь-якою оо мовою? :)

Е-е, не зрозумів вашого питання.

не уявляю код на java з одними примітивами :) Чи я не так те зрозумів?

А до чого примітиви до алгебраїчних типів.?

приклад алгебраїчних типів даних можна привести? що це таке і з чим його їдять?

Алгебраїчний тип складається з кількох типів, кожен з яких створюється своїм конструктором.
Наприклад Bool можна уявить як алгебраїчний тип з конструкторами True та False.
Або заміну ніл-поінтеру Optional[T] як штуку з конструкторами Nothing[T] та Some[T](value T).
У мовах, що мають алгебраїчні типи, вони «пам’ятають» конструктор що їх породив, хоча ззовні мають один і той же тип. Це постійно використовується для паттерн-матчінгу.
В ООП-мовах ця поведінка емулюється інтерфейсом та класами що його імплементують.

ах ось що це таке. Так, Optional паттерн — дуже корисна штука.

Чудово.

Але як це убезпечить від перевірки змінної, чи там у нас Nothing[T], чи Something[T]? Все одно треба перевіряти або робити (перегружені) версії функції, які будуть матчити по патерну.

Або якщо у нас змінна ініціалізована як Nothing[T], але я звернусь до одного з членів даних класу T — що буде? Яка тоді принципова різниця з перевіркою на NULL?
Ну, або більш загальне питання — чи так важливо нам мати типізоване «ніщо» замість нетипізованого?

Суть в тому, що якщо ви хочете витягнуть значення з такого контейнера, ви зобовязані явно вказать про це: x.getOrElse(defaultValue). Або ж кидать ексепшн, або перевірить попередньо, а чи є там щось.
Ще наприклад їх обробку можна покласти в конвейєр типу x.map(value => nextValue).map(value => nextValue) і якщо десь опиниться Nothing, то воно автоматично вилізе напочаток.

чи так важливо нам мати типізоване «ніщо» замість нетипізованого?
Ну це нюанси мови програмування. Я написав на абстрактній скалаподібній мові. Може в скалі воно як у хаскелі, data Maybe a = Just a | Nothing.

Ясно. Нема щастя на білім світі — навіть з продвінутими поінтерами треба перевіряти, що там лежить :)

Ну, чому. В хаскелі такого поняття як вказівник (втч нульовий) не існує, тому якщо функція вимагає якийсь тип на вхід, то будь бобр передать конкретне значення. Якщо автором передбачається і потім хендлиться відсутність значення, це аннотується опшнлами.
Це не класичні мови, де бомба може бути підкладена в будь-який обєктний тип.

Насправді що чиста динаміка що чиста статика мають свої переваги. Але коли тобі жсон шле пехопешка, а ловити і розбирати його треба на Go, тут і починаєш осягати дзен.

Пишеш структуру на го, аннотуєш жсон полями, профіт.

От. А якщо хтось розпихав у стрічкові атрибути фолс, коли в базі порожньо?:)

Ура, холивар! Спасибо за статью.

Интересно, что ровно в то же время как в PHP добавляется строгая типизация, в Java добавляются дженерики, чтобы эту строгую типизацию ослабить. И одновременно туда и туда добавляется функциональщина (которую ПХП-стам, наверное, даже проще понять, ибо SQL — хороший пример функционального языка и его традиционно тоже знают).

Я регулярно делаю Triage вопросов от новичков на Stackoverflow и там по тэгу РHP уже больше половины вопросов по фреймворкам (в основном ларавель), хотя и мусора в стиле всё напихать в один файл и спрашивать, где ошибка, тоже хватает.

А так с выводом согласен, пошёл смотреть курсы по Яве для расширения мозга горизонта.

SQL — хороший пример функционального языка и его традиционно тоже знают).

Lisp, Scala хорошие примеры функциональных языков, почему считаете sql функциональным?

SELECT запросы по сути — это описание того, как нужно взять данные и куда трансформировать. Нужно навалить кучу условий, группировок, правил присоединения, подусловий и в конце получить большую формулу, в которой без бутылки не разберёшься, точно как и в ФП. По итогу оно очень похоже на цепочку map/filter/reduce, просто немного по-другому написано. Не знаю, может это только у меня такая ассоциация, конечно.

точно как и в ФП
разве, это не про декларативные ЯП речь? которые, уже, в свою очередь могут быть логическими или функциональными.
SQL — декларативный язык.
по каким признакам он именно функциональный?

Да, я таки ошибся, спасибо за поправку, SQL формально не функциональный. Кому как, но мне лично знание SQL, позволило чуть меньше сломать мозг на курсе Скалы Одерского.

SQL — хороший пример функционального языка и его традиционно тоже знают
што?

SQL не является функциональным языком даже близко. Особенно это касается MySQL, который в большинстве своем и знают PHP-шники.

Реализация SQL в MySQL хоть и отклоняется от стандарта, но это тема отдельного холивара (спойлер — Постгрес лучше его поддерживает). Вот тут хорошее сравнение, кстати. Но не суть. Если посмотреть на примеры сложных SELECT-ов, то по сути это формулы получения и группировки данных, у меня это вызывает стойкую ассоциацию с формулами преобразования через map/filter/reduce. И там и там в конце фиг что поймёшь.

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

тут долго смеялся :D

і постійні ексепшни джава-машини, які не зрозуміло, як правильно ловити, і зовсім не ясно, як потім фіксити.
- откуда такая информация? :)

Це особистий досвід, як з джавою, так і зі скалою і кложурою. Не знаю, може з личкою мідла отримуєш заодно і резістанс до такого, але я поки не отримав :)

Это Callstack, а не Exception.

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

Ну так-то да, только вот HR и работодатели не всегда разделяют ваше мнение :)

А які проблеми у JS?

Якщо з точки зору пропозицій, то останнім часом JS навіть дуже популярний — кожні пів року новий фреймворк.

Асинхронные приложения всегда сложно дебажить, в независимости от языка. В JS примерно же инструменты дебага, что и в пхп.

ну если под

Асинхронные приложения
ты имеешь ввиду ajax + php c phpStorm дебажить нефиг делать.
Как в angular или react + node.js не знаю, но подозреваю что сложнее ибо callBack дебажить у меня не получалось только при помощи console.line

stackoverflow.com/...ebug-node-js-applications
пробовали эти модули?
самое привычное — инетграция с IDE.
самое быстрое — ставить модули и дебажить серверную часть через дебаггер в браузере

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

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

А IDE для JS, то WebStorm обычно использую.

сложно выбрать фреймворк/библиотеку)

1. this
2. prototype
3. =>
3. [] + [], [] + {}, {} + [], {} + {}

ага. а еще ++, ;, GC, замыкания и возможность создавать глобальные переменные

1. this
2. prototype
3. =>
мега крутые штуки, регулярно использую.
3. [] + [], [] + {}, {} + [], {} + {}
Для этих операций есть соотвествующие функции, в реальных проектах так никто не делает.

Чувак, пиши ще!
Дякую за статтю. Давно не читав нічого настільки хорошого, написаного живою українською. :)
P.S. Ображені товариші по цеху (PHPшники) — шо ви зразу в «стойку захисту» стаєте і роказуєте про те шо PHP найкращий і нікуди не тре йти.
Стаття повна сарказму(сатири) і мені здається трохи не про те що PHP поганий, а про особливості життя на інших планетах :)
P.P.S. Якщо я правильно прочитав, то автор нікуди не пішов і далі пише код на PHP

Вообще, стиль написания статьи крайне напоминает одного известного на Украине Java разработчика.

Если в годах так 2011-13 эти шютки про пхп-неязычность ещё были оправданны отсутствием нейспейсов, малой применимостью паттернов и solid, буквально единицами практикующими написание юнит-тестов, то сейчас... О чем статья? Зачем куда-то переходить? Язык, который еще 5 лет назад состоял из поделок уровня первого Yii с кучей магии, публичных свойств и повсеместным нарушением принципов SOLID остался только в нелепых CMSных процедурных поделках!

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

Один остался жить в 2011, чей венец первый Yii, где до сих пор клепают сайты-визитки и «магазины» на выброс в подвалах вебстудий. Там постепенно идет переход на второй Yii, на котором, впрочем, пишут ничуть не лучше, чем писали на первом, хотя фреймворк довольно современный и писать хороший тестируемый код на нём можно. Просто люди без образования, чьим первым опытом была какая-нибудь CMS считают, что так и надо делать сайты. (они именно делают сайты, а не приложения в широком смысле вроде API, демонов и т.п.) На своей первой работе я когда-то от такой атмосферы плевался, но в моем городе ничего кроме PHP не было и тогда, собственно и посещали мысли перейти в PHP на что-то другое. Но потом я узнал про симфони 2. :)

Второй мир — это PHP5.6-7, Symfony2-3, Zend2. Где применяются паттерны, на собеседованиях заставляют рассказывать о солид и объяснять какой принцип нарушает приведенный пример говнокода на листочке, юниттесты пишутся почти везде, ООП обязательно, PHPDoc каждого метода, кодревью, git flow, асинхронные задачи, nosql... Полно всяких энтепрайзных решений в плане архитектуры. Event-driven development, SOA, это реальность. Все по-серьезному, для всего есть библиотеки и экстеншны. Зарплаты всего-лишь на $500 ниже джавистовых и за последние несколько лет именно зарплаты симфонистов\зендистов выросли и почти джаву догнали. Синьер $3k+. В Европах сертификация по фреймворкам, по core языка непосредственно от Зенда.

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

PHP7 вообще сказка, сбылась моя мечта, пхп наконец становится языком общего назначения с нормальной типизацией...

пхп наконец становится языком общего назначения
уже можно писать игры и мобильные и десктопные приложения?

В пхп5 были проблемы с вытеканиями памяти в долгоживущих процессах. Поэтому всякие воркеры и демоны, постоянно висящие, было принято перезапускать раз в какое-то время. Это да, делало проблематичным разработку десктопных приложений. Но возможность такая есть. Подключайте библиотеку QT и наслаждайтесь возможностью работать с QTшными компонентами на PHP. В семёрке обещали, что эту проблему исправят, я лично не проверял пока.

Что касается игр, в интернете полно примеров консольных и текстовых игр на php. Там, где не жрется много памяти, процессы хорошо висят и не падают.

Насчет мобильной разработки — тут не знаю.

Накатал аргументов на страницу... и хром помер. Ладно вкратце
пхп 7 опоздал.

Сочувствую. У PuntoSwitcher есть функция Дневник куда сохраняется весь текст что напечатали.

практически 90% всего сегмента браузерок и социалок на РНР ))

Как в ПХП реализовать Unit of Work?

где именно доктрина держит объект над которым происходит работа в рамках бизнес-транзакции?

Доктрина берет spl_object_hash() от объекта, над которым надо проделать insert/update и хранит его в массиве вида
$entityInsertions = [ spl_object_hash($entity) => $entity]; (если речь идет об инсертах)
Такие же массивы для update/delete.
Массивы хранятся в памяти. Если их заперзистили, но не зафлашили, то при die() эти массивы очистятся.

а как происходит разшаривание объекта между запросами? ну вот одним запросом я отредачил одно поле, вторым — второе. как доктрина хэндлит, что это один и тот же объект?

UnitOfWork следит за изменениями объекта и шедулит объект на insert/update/delete, если он таковые изменения видит. Он ни с какими запросами не работает и даже не имеет понятия о том, даже какой тип СУБД используется. Потому что он знает только про уровень объектов и максимум что может — это в зашедулить в нужном порядке insert/update/delete.

Уровень запросов доктрина хендлит с помощью Persisterов. Для каждой СУБД разных. Перзистер вызывается, когда происходит flush(). Выгребаются все вот эти изменения зашедуленные и персистер делает им типа executeInserts() или аналогичное. Там старается как-то оптимизировать несколько запросов в один пакетный, если это возможно. Ну и собирает сам SQL. Персистер можно и отдельно использовать.

Когда, например, новая сущность заперзистена и зафлашена она становится managed, то есть про неё знает entityManager, она через него связана с конкретной строкой в таблице БД. Тоже самое, если сущность выбрать из БД запросом. Доктрина смотрит на первичные ключи и менеджит по ним (композитные тоже шарит). Тоесть если ты сделаешь refresh managed сущности, то доктрина перечитает по первичному ключу связаную запись, сработает гидрация поновой и у тебя будет актуальный объект. Если поменять первичный ключ, а потом перечитать, тогда жопа, да. Но на моей практике такого никогда не было.

Видимо, я неправильно сформулировал вопрос.
Unit of Work работает с объектами в контексте бизнес-транзакции, которая вполне может состоять из нескольких запросов. Под запросом здесь подразумевается не SQL-запрос, а обращение к серверу. Условно говоря, я открыл форму редактирования объекта, изменил одно поле(запрос ушел), почесал репу, изменил еще пару полей(запросы ушли), первое поменял на старое значение(запрос ушел), потом только нажал кнопку OK(пошел flush). То есть я посылаю к серверу несколько запросов на изменение объекта, но в базу заливается только его конечное состояние.
Насколько я знаю, по окончанию кажого запроса в ПХП вся память, которая выделена под этот запрос чистится. Соответственно мне непонятно, как происходит реализация передачи этого объекта между несколькими запросами в контексте бизнес-транзакции.

Так PHP не сидит в памяти постоянно. Он же «создан, чтобы умирать». Каждый запрос — это отдельный инстанс, в котором поднимается PHP, весь фреймворк, инициализируется доктрина и т.д. Поэтому обычно если уже посылают запрос на сервер, то в конце, если все объекты изменились и все ок, делают flush(). Если флаш не сделать, изменения потеряются.

Но я не до конца понимаю зачем делать, указанное вами. То есть, при нажатии на кнопку «ОК» и так уйдет вся форма целиком, объект сущности изменится в соответствии с переданной формой (если она валидна), потом произойдет флаш и объект обновится. А в чем смысл посылать несколько запросов на изменения объекта, не делая флаша?

Вообще, конечно, можно сделать php демоном, который будет висеть в памяти все время и ждать каких-то параметров, тогда все существование демона в памяти заперсисченные данные будут лежать вот в том массиве $entityInsertions, а потом произойдет flush() и они разом применятся. Но для веба это какое-то извращение, зачем, если на 1 request надо отдать 1 response?

А в чем смысл посылать несколько запросов на изменения объекта, не делая флаша?

Мб я привел не лучший пример. Но это оооочень распространенный в энтерпрайзе кейс. Потому что:
1. Один объект могут редачить одновременно несколько клиентов и необходимо реализовать оптимистическую блокировку.
2. Объект может модифицироваться не юзером из формы, а приложением, при чем между модификациями в рамках одной бизнес-транзакции могут проходить относительно значительные временные промежутки.
3. В принципе, советую погуглить кейсы длинных бизнес-транзакций.
4. Хотим улучшить юзабилити и сейвим, но не сохраняем в бд, состояние объекта, который юзер модифицирует, чтобы если он откроет в другой вкладке форму или случайно закроет, а потом заново откроет ту же форму, сохранились уже введенные значения.

Собственно говоря, когда я работал с Доктриной, это было года четыре назад, то обратил внимание, что Unit of Work в Доктрине это не классический юнит оф ворк из книжек Фаулера, а скорее инструмент оптимизации sql-транзакций.

Я понял вас. Реализовать оптимистическую блокировку в работе с доктриной можно. К сущностям нужно добавить поле $version и аннотировать его как @Version с типом данных int или там dateTime. Доктрина посмотрит на эту аннотацию и автоматом будет инкрементить поле (или ставить текущую дату). Потом, при селектах вы указываете необходимый номер версии и OPTIMISTIC LockMode. Если версия не та, доктрина бросит соответствующий эксепшн, который вы обработаете.

Но хз как это использовать, когда на 1 реквест поднимается инстанс, а потом все умирает. Между этими реквестами надо это дело где-то хранить самому. С семеркой, наверное, будет уже получаться запускать пхп как именно сервер, постоянно живущий и это все заведется так, как хотите вы.

А где хранится эта версия? В базе данных?

как хотите вы.
Это не я хочу, это общепринятые требования к Unit of Work ;)

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

Он же «создан, чтобы умирать».
Теперь нет. Это была основная проблема, он не мог работать долго.

И кросс-реквест видимость объектов тоже добавили?

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

Простоту оцінили і вчені. Стільки наукових бібліотек, як на Пітоні, нема в жодній мові. Тому якщо ви збираєтеся заглибитися в машинне навчання — особливих альтернатив у вас практично нема. Ну, хіба ще Lua, але екзотику ми зачепимо трохи пізніше.

Є альтернатива — R. Там якщо не більше, то принаймні не менше бібліотек для машинного навчання. Я застосовував моделі штучних нейронних мереж, дерев прийняття рішення і т.п. в ньому до даних.

Файна стаття!

R це теж круто, але я більше бачу її, як допоміжний стек для аналітиків чи науковців. На кшталт Матлабу чи Математики. Пітон все ж дає ширший діапазон розвитку, а разом з тим і більшу кількість вакансій :)

Існують дослідження про те, що в мозку є спеціальний відділ для розуміння базових принципів JavaScript. Він дістався нам напряму від рептилій і ні в вербальну, ні в навіть графічну форму, це знання не конвертується.

это прекрасно!!

Автор, а що скажете про Python?

Норм! Я на PHP c 2001 года по сегодня. Миграцию быдлокодеров с PHP на другие платформы только поддерживаю :-)

вброс защітан, автору пять балов

Отличная статья, спасибо автору. Во-первых, за отличный обзор ситуации с языками программирования, а во-вторых, за слог. просто зачитался. Ну и рекомендую к прочтению всем моим студентам :)
П.С. Я, кстати, на джаву как раз с РНР перешел (хоть и было это 15 лет назад), так что автора более чем понимаю.

за 15 лет PHP немного смогло подрасти)

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

Статья, конечно, разжигатель пуканов еще тот :). Глядишь, обиженные соберут «крестный ход» и спалят автора на костре.
P.S. Будьте проще, воспринимайте статью как субъективное мнение автора :)

Зато, написано интересно :)

А зачем тогда лента, если не «растекаться мысию по древу»
3-5 коротеньких предложений они и так всем очевидны

Если коротко:
1. PHP отстой
2. Нормальные вещи на PHP написать невозможно (независимо от уровня разработчика).
3. Переходите с PHP хоть куда-нибудь, хоть на JS.
4. Сейчас огромный спрос на разаботчиков без опыта в любой технологии.

Где-то так.

1. И не пробовал.
2. Это было резюме статьи.
3. Это был настолько тонкий сарказм, что не все смогли это понять :)

огромный спрос на разаботчиков БЕЗ ОПЫТА В ЛЮБОЙ ТЕХНОЛОГИИ
мне кажется, тут сарказм много тоньше )

Я понимаю, что раскручиваю вентилятор, но позвольте поинтересоваться: что в вашем понимании «нормальные вещи», которые так невозможно записать на PHP? Про пассаж «независимо от уровня» пока что промолчу...

Прочитайте комментарии выше.
Повторю:
1. Это было резюме статьи.
2. Это был сарказм.

Всім відомо, що, починаючи з останніх версій п’ятірки, PHP поволі стає на шлях ентерпрайзу

Затраллел

кілька ваших стрічок коду
А разве есть такое слово?

котре саме? ніби всі з перелічених є)

стрічка — это вроде как лента, не? Лента кода? Это как?

«Рядок[1], також, застаріле, стрічка[2] — кілька слів, літер або інших знаків, написаних чи надрукованих в одну лінію.»
uk.wikipedia.org/wiki/Рядок

що?! яке застаріле... я би в вікі граматику не перевіряв. Правильно — рядок, стрічка — це русизм.

Я замінив у статті, мабуть не варто тут в коментарях розвивати ще й мовні граматичні баталії :)

Те, що коректно вживати рядок — факт) Щоправда, багато людей все одно каже «стрічка».
Стрічка — русизм? Не впевнений.

Історія вживання слова «стрічка» стосовно рядочку коду сягає коренями в історію комп’ютерної техніки. В давнину код писали на довгих шматочках паперу з дірками, так званих «перфострічках». Технологія давно уже канула в Лету, але слово встигло прижитись.

А якщо серйозно, депрекейтити слова чисто через наявність аналога в російській — хороший спосіб збіднення синонімічного ряду мови. Давайте ще випиляємо слова, аналогічні польським. Наприклад, «рядок». Явний ж полонізм :)

Слово було депрекейтед ще в 70-80 роках минулого століття, судячи з
sum.in.ua/s/strichka

Если это троллинг, то очень «тонкий». Не все еще достигли такого уровня просвещения.

міски засирали такою пропагандою
Якщо так подумати, то все — чиясь пропаганда. Своя голова повинна бути на плечах.
як не як, а один з останніх ресурсів, які я ще читаю )
А я хочу бачити в одному місці максимальну к-сть різних думок. І сам робитиму висновки.
пишіть менше такого лайна
У мене для тебе погані новини...

Вибачте, а «заказну» ким? :)

У нього зрада головного мозку.

Че на автора так накинулись? Написано с юмором, мне понравилось. Хоть к пхп вообще отношения не имею.

Після четвертої-п’ятої прочитаної книжки є всі шанси зрозуміти патерни проектування. Заодно, щоправда, зрозуміти і те, що вони нікому не здалися. Але це вже зовсім інша історія.
наверное все же «піти», вообще из айти

Давно не было PHP Haters статей.
Я уже начал думать, что-то случилось...

ну PHP 7 вышел и все укекались.

Відсутність нормального ООП з усіма його заморочками
В пітоні нормальне ООП. В джаваскрипті теж нормальне.
Просто інше, аніж в джаві та мовах, що з неї фічі дерли.
Недоліки. Ніша, якою б вона широкою не була, лишається все ж нішею. Будь-які сподвижки в розробці мобільних сайтів можуть дуже швидко урізати ринок як мінімум вдвоє. Популярність платформи теж не вічна — подивіться, що сталося з віндофонами.

Что-то не совсем понял, причем тут сравнения видоусфона и андройда. Я лично пока не вижу альтернативы андройду, может вы мне её покажете? И как мобильная версия сайта может заменить полноценное приложение?

Прекратил читать после

Після четвертої-п’ятої прочитаної книжки є всі шанси зрозуміти патерни проектування. Заодно, щоправда, зрозуміти і те, що вони нікому не здалися. Але це вже зовсім інша історія.

Если это не тщательно замаскированный сарказм, то эта фраза очень много говорит о качестве кода автора (и качестве продуктов конторы, в которой он работает сеньором).

Адекватные РНР-шники,скажите, а у вас совсем нет места SOLID, паттернам и т.п., или это проблема одного конкретно взятого сениор софтваре инженера?

Конечно используются
Раз в несколько лет, когда собираешься идти на собеседование и нужно вспомнить весь этот булщит

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

Ну рискну предположить, что причин две:
* Изначально сравнительно низкий порог вхождения именно в сайтостроительство
* Тайтл «сениор» давется не за знания и умения, а за кол-во лет опыта в резюме и отработку жопочасов. Ну и плюс желание выставить рейты повыше заказчику.

Рискну предположить что года через 3-4 та же ситуация будет c JavaScript-девелоперами

что года через 3-4
если повезет, то нормализуется. а так — уже.

жалеть о смене чего бы то ни было — вообще так себе занятие.

Ваша думка дуже важлива для нас.
Над вами знущалися злі похапешники, що ви при кожній нагоді не забуваєте згадати факт зміни мови програмування?

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

Прикольный стеб получился.
Если по существу то на джаве тоже есть стартапы и фриланс — правда технология — Android.

За JS точно такиеже иллюзии как у многих за PHP.

Дальше сеё письмо не осилил, особенно после того как Scala объеденили с Go

Ну почему, вот, давиче, пришло письмо от мадам которая предлагает «партнер Senior Java» в стартап с долей. Требования прицеплю на всяк

Плюсом будет опыт написания web crawler-ов
Нужно чтобы у Вас было от 4х лет опыта коммерческой разработки на Java
Нужен опыт: Spring Core, Spring Boot, JPA, Solr, MySQL, tomcat, spock, jacoco
Плюсом будет: MS SQL Server, flyway, gebish

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

Вот очень хочется нецензурщиной ответить, но не буду. WTF вообще? Автор, что вы курите?

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

Надо было жестче, чтобы у людей, которые только посматривают на IT или учатся, сразу отбивало желание кодить на PHP. Серьезно, вы делаете хорошее дело — становится гораздо свободнее дышать в поисках работы. Так что да — да, пхп — несерьезно, низшая лига, при виде разработчика на пхп сразу отворачивает.... Пишите еще :)

Я знаю авторитетного разработчика который утверждает что Java-девелоперы это лохи, и конец эпохи Java уже не за горами. Сам он приверженец С#. Это я к чему. Послушать вас, этаких умников «мега-экспертов», которые гнобят другие языки, и понимаешь, что нихрена вы, ребята не понимаете ни в программировании, ни в самой жизни. А истина в том, что:
«Каждый инструмент оптимален для выполнения конкретной задачи. Осознал задачу, выбирай инструмент». Поэтому я люблю PHP, уважаю JavaScript, ценю Java, C#, Python, другие языки, и всех разработчиков, которые на них пишут.
Ваша фраза насчет «отворачивает» — это показатель вашей ущербности.

Вы знаете, что хамить незнакомому человеку- признак быдла?
Я мог бы попросить вас включить в своих настройках юмор, хотя бы на минимум, и перечитать мой пост еще раз. Если вы все равно не увидели там иронию, я поясню — я имел в виду, что чем больше людей будут вестись на подобные бредни, что «пехопе для лохов, это быдлокодеры», и т д, тем больше мне, использующему PHP как основной серверный язык, будет легче жить — моя ниша не будет переполнена, со всеми позитивными моментами, из этого тезиса вытекающими.

P.S. Ваш агрессивный тон — признак вашей закомплексованности, судя по тому, как быстро вы, не разобравшись, кинулись на амбразуру. Языки вы любите, а людей, похоже, не очень.

«Если бы ты сказал фразу „при виде разработчика на пхп сразу отворачивает“ мне в лицо, я бы тебе яйца оторвал» — вот это агрессивный тон. То что я сказал — это комментарий по вашему тексту, без какой либо агрессии. Выражайте свою мысль яснее.

Касательно Java.

Влаштуватися, як не дивно, вдається практично всім.

Это 80-й уровень сарказма?
Просмотрите количество вакансий без опыта работы на позицию Java разработчика.

А вот не надо путать

без опыта работы — вообще
с
без опыта работы — конкретно в Java, но 10+ в отрасли

Совершенно разные люди

В статье писалось:

кожного року на ринок висипає нова тисяча джуніорів, потреба в спеціалістах все одно лишається високою

А не:
«кожного року на Java переходять багато досвідченних розробників з інших технологій».

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

А що, Сайбервіжн і Парус вже не набирають?)

Есть компании, которые набирают, но они не в состоянии обеспечить тысячи специалистов без опыта рабочими местами )
Поэтому большая часть остаётся за бортом, а пробиваются только самые настойчивые (хотя, это может и к лучшему — касательно настойчивости).

Підписатись на коментарі