Да, GOTO это конечно феноменальный отжиг :) Ну ничего, тут пофиксить - там поправить... добавить set_goto_handler()/restore_goto_handler(), поддержку новоиспеченных namespace'ов в goto, поддержку объектной модели, а-ля goto array($object, 'label'); ну и т.п. - и всем языкам будет язык :)
Автор просто ошибся, это тернарный оператор сокращенный, а GOTO обычный... в общем это начало конца, лучше я сейчас утоплюсь, чем потом буду натыкаться скрипты такого рода революционными фичами...
Честно говоря слабо могу себе представить ситуацию, когда переданные из другого модуля сериализованные данные должны быть сразу отправлены во фронтэнд, обычно такие данные используются для того чтобы изменить поведение конечного модуля, а их для этого соот-но нужно десериализовать.
Для инженера, настоящего темного властелина, конечно-же не имеет значение на чем писать, зачем писать, и как долго :) Сказали писать не на PHP а на Perl'е - потратил месяц на изучение Perl'а, потом еще пол-года на изучение его специфических особенностей, параллельно с отладной написанных на нем нерабочих программ - и вперед, сказали писать на Jav'е - еще пол-года, итого лет за 10 можно заиметь вполне себе многоцелевого программиста, правда PHP он уже к этому времени забудет, потому если вдруг - еще пол-года и... Нанимают-то обычно тех кто готов работать сразу, или подразумевается что инженер-программист при трудоустройстве уже знает все мыслимые и немыслимые языки? Ну тогда уже для конторы не должна иметь значение сумма, которую он запросит за свои услуги :)
Так что имхо профессия-то может и общая, а специализация в ней должна быть своя. Конечно это не отрициет того что теоретически принципы программирования хороший программист должен знать во всем их многообразии, даже если к языку в котором он специализируется они не относятся, но боюсь что страсть к самообразованию не критерий для трудоустройства, потому как ведрами ее мерять проблематично.
А насчет верстки - так уж сложилось что в основном языками программирования называют империтивные языки программирования, а верстка относится к декларативным, где реализация описывается не программистом, а заложена в интерпритатор (в данном случае браузер), и специфика у нее другая, научиться верстать - невелика наука, а знать что при третьем диве слева такой-то браузер дает 8 пикселей справа - на это опять-же нужно время.
Работаю в небольшой конторе на 10 человек, 3 программистов, требования - PHP5 c ООПъектами там всякими, MySQL, JavaScript. Раньше требовали знание HTML/CSS, но после продолжительного нытья на луну, со стороны PHP-программистов, верстку из обязанностей вычеркнули, верстают теперь левые дяди, хотя скорее всего при трудоустройстве знание принципов верстки, при прочих равных, будет неплохим плюсом.
Если говорить в общем - это скорее всего больше зависит от размера конторы, если в маленькой студии, где из персонала один человек (и чтец, и жнец, и на дуде игрец) - требуется вообще все: верстка, программирование, проектирование БД, а еще дизайн, раскрутка и навыки общения с клиентом, то по мере роста конторы обязанности можно (и нужно) распределить, один человек действительно не может быть специалистом во всем одновременно, да и не нужно это, потому как грамотное распределение труда всегда будет давать ощутимый прирост в скорости разработки по сравнению с бюджетными решениями а-ля Вася-Пупкин-All-Included, так как даже если знаешь две каких-либо области на отлично - чтобы переключиться от одной к другой все равно потребуется время.
Да, вообще впринципе наболевшая тема - отделение модели от представления, некоторые даже пытаются реализовать шаблонизатор так, что в нем вообще как факт отсутвуют элементы логики, а вся логика реализуется в коде...
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.
Да, я как-то тоже не сторонник такого рода систем, да и насчет "все предусмотреть невозможно" - тоже имхо неправильная позиция, можно предусмотреть, если специально этим озадачиться, иже введя например доп.абстракцию, одна лишняя функция/метод, в которую отдельно передаются запрос и параметры оного (с последующей обработкой оных) - уже избавляет от проблем с sql-инъекциями, также можно централизовать обработку данных, пришедших с форм, из адресной строки и т.п., да и вообще проверка наличия того "что нельзя" всегда будет уступать проверке на соответствие тому "что можно".
Так что имхо профессия-то может и общая, а специализация в ней должна быть своя. Конечно это не отрициет того что теоретически принципы программирования хороший программист должен знать во всем их многообразии, даже если к языку в котором он специализируется они не относятся, но боюсь что страсть к самообразованию не критерий для трудоустройства, потому как ведрами ее мерять проблематично.
А насчет верстки - так уж сложилось что в основном языками программирования называют империтивные языки программирования, а верстка относится к декларативным, где реализация описывается не программистом, а заложена в интерпритатор (в данном случае браузер), и специфика у нее другая, научиться верстать - невелика наука, а знать что при третьем диве слева такой-то браузер дает 8 пикселей справа - на это опять-же нужно время.
Если говорить в общем - это скорее всего больше зависит от размера конторы, если в маленькой студии, где из персонала один человек (и чтец, и жнец, и на дуде игрец) - требуется вообще все: верстка, программирование, проектирование БД, а еще дизайн, раскрутка и навыки общения с клиентом, то по мере роста конторы обязанности можно (и нужно) распределить, один человек действительно не может быть специалистом во всем одновременно, да и не нужно это, потому как грамотное распределение труда всегда будет давать ощутимый прирост в скорости разработки по сравнению с бюджетными решениями а-ля Вася-Пупкин-All-Included, так как даже если знаешь две каких-либо области на отлично - чтобы переключиться от одной к другой все равно потребуется время.
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.