Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
Дочитал до середины, хотя было желание остановиться после слов «я не программист». Какая ключевая мысль-то всего этого? Автор пробовал узнать сколько технологий используется в комьютере, на котором он набивал этот текст?
PHP — возможно раньше и был шаблонизатором. Я не знаю историй других языков особо подробно, но представьте, если бы руби, например, изначально был придуман для описания логики микроволновок, и только для них, и спустя 10 лет, когда руби уже все умеет и могет, его используют в качестве бекэнд-сервера, на нем написан пакетный менеджер, и много всего хорошего, кто-то сидит и рассуждает «ха-ха, вы что, используете руби для бекэнда? Это же язык для микроволновок!»
Кстати стоит задуматься над тем, что php == шаблонизатор изначально успешный маркетинговый ход, всем хотелось динамических сайтов, вместо набора html, ровно как и название javascript и еще куча подобных вещей
PHP — возможно раньше и был шаблонизатором. Я не знаю историй других языков особо подробно, но представьте, если бы руби, например, изначально был придуман для описания логики микроволновок, и только для них, и спустя 10 лет, когда руби уже все умеет и могет, его используют в качестве бекэнд-сервера, на нем написан пакетный менеджер, и много всего хорошего, кто-то сидит и рассуждает «ха-ха, вы что, используете руби для бекэнда? Это же язык для микроволновок!»
Кстати стоит задуматься над тем, что php == шаблонизатор изначально успешный маркетинговый ход, всем хотелось динамических сайтов, вместо набора html, ровно как и название javascript и еще куча подобных вещей
Всё это так или иначе завязано на HTTP over TCP over IP over Ethernet (правда, внутри одного сервера могут использоваться сокеты межпроцессного взаимодействия). Семь (!!!) технологий для одного сайта! Нет, ну это правда нормально?
Да, это абсолютно нормально. Просто потому, что IP не обязательно используется с TCP; по TCP работает не один HTTP, а HTML, JS и прочие никак не привязаны (и не должны быть привязаны) к протоколам передачи данных. И сделано именно так было не без причины. Интернет — это не только браузеры, показывающие странички, и сервера с вордпрессами.
//Дальше не читал
Это не то чтоб «нормально»/«ненормально», это вообще «а как же иначе?!»
Автору еще можно рекомендовать заглянуть сюда: ru.wikipedia.org/wiki/%D1%E5%F2%E5%E2%E0%FF_%EC%EE%E4%E5%EB%FC_OSI
Автору еще можно рекомендовать заглянуть сюда: ru.wikipedia.org/wiki/%D1%E5%F2%E5%E2%E0%FF_%EC%EE%E4%E5%EB%FC_OSI
Очень прошу: отметьтесь те, кто добросовестно прочитает весь текст с начала до конца. Интересно, много таких?
Дочитал. Скажу так, те кто не дочитал ничего не потеряли :)
Автор до сих пор считает php шаблонизатором, говорит о низком пороге вхождения и при этом не смог осилить Yii.
Много воды, и при этом я так и нашёл ответа «почему PHP — велосипед».
Автор до сих пор считает php шаблонизатором, говорит о низком пороге вхождения и при этом не смог осилить Yii.
Много воды, и при этом я так и нашёл ответа «почему PHP — велосипед».
Прочитал, добровольно, полностью. Навеяло только одну мысль:
Макаревич:
И лишь только тот, Кому нечего сказать,
Громче всех кричит, Он громче всех кричит.
Макаревич:
И лишь только тот, Кому нечего сказать,
Громче всех кричит, Он громче всех кричит.
Знаете, у меня сложилось впечатление, что у автора в голове крутится большой взгляд на всю отрасль. И очень большое желание крикнуть «Что же вы все делаете?!». Но, даже понимая, сколько нужно написать и разложить, как минимум, для себя в голове все причинно следственные связи, он решился написать свою мысль очень скомкано и по быстрому. Т.к. уже устал держать это в себе.
Я более чем уверен, что каждый кусочек написанный тут, он сможет обсуждать часами с хабражитилями, но тогда бы, он писал это вечно.
Я более чем уверен, что каждый кусочек написанный тут, он сможет обсуждать часами с хабражитилями, но тогда бы, он писал это вечно.
У меня в голове крутится большой взгляд на политические темы, но если я буду об этом говорить, мои слова будут неразумными т.к. мне по сути нечего сказать т.к. я не понимаю достаточно глубоко те процессы.
Писать нужно тогда, когда есть о чем поведать, когда мысли структурированные и подкреплены чем-то более серьезным.
Писать нужно тогда, когда есть о чем поведать, когда мысли структурированные и подкреплены чем-то более серьезным.
Я тоже напрасно потратил время и прочитал до конца.
Прочитал полностью, выскажу свои претензии автору:
Нуну, глобальные переменные и синглтоны видимо рулят.
О_о?!?!?
Кэшировать можно байткод кстати.
Можете считать, что соответстующие банлы разных фреймворков и есть DSL для этих нужд.
Ох, что-то надоело… Вобщем, я не удивляюсь, что человек, который веб-разработку краем глаза видел, такие мысли рождает. Но они — от незнания инструментов. Я сам когда-то думал: «как же так? интерактивные приложения и stateless протокол под капотом?», а потом открыл для себя очень много интересных вещей.
Предлагаю автору познакомиться с node.js =)
единожды проинициалированная переменная в доброй половине случаев может быть использована хоть через год работы программы
Нуну, глобальные переменные и синглтоны видимо рулят.
Любой тогдашний средний сервер обзавидовался бы… разрешению экрана
О_о?!?!?
различных степеней парсинг
Кэшировать можно байткод кстати.
Если парадигмы User/Password и Post/Comments настолько прочно обосновались в веб-технологиях — почему работа с ними, включая хранение, до сих пор не выведена на уровень стандарта языка или протоколов?
Можете считать, что соответстующие банлы разных фреймворков и есть DSL для этих нужд.
Ох, что-то надоело… Вобщем, я не удивляюсь, что человек, который веб-разработку краем глаза видел, такие мысли рождает. Но они — от незнания инструментов. Я сам когда-то думал: «как же так? интерактивные приложения и stateless протокол под капотом?», а потом открыл для себя очень много интересных вещей.
Предлагаю автору познакомиться с node.js =)
Тогда уж не node.js а JS, node — всего лишь I/O фреймворк.
На вкус и цвет… Лично мне не мешает
Да ладно, ну сколько можно? Как говорят на ЛОРе — 4.2. В ES6 уже и ключевое слово «class» ввели для тех, кто без него не может жить и программировать.
rust посмотрел, забавно, но у него есть как минимум один недостаток, v8 его не исполняет :)
критируется за динамику
На вкус и цвет… Лично мне не мешает
отсутствие ООП
Да ладно, ну сколько можно? Как говорят на ЛОРе — 4.2. В ES6 уже и ключевое слово «class» ввели для тех, кто без него не может жить и программировать.
rust посмотрел, забавно, но у него есть как минимум один недостаток, v8 его не исполняет :)
Дочитал. У автора жуткая каша в голове.
к сожалению, «ни асилил».
Отборнейший поток сознания =)
// Прочитал почти все, но не по порядку
// Прочитал почти все, но не по порядку
что PHP — всего лишь шаблонизатор.
Дальше не читал
Правильно сказать «PHP _изначально_ шаблонизатор», но многие «фичи» такому успешному и популярному проекту, _пришлось_ оставить в угоду популярности.
У php многое от шаблонизатора, а меня завтра будет хорошее настроение, и много минусов )))
Как идея сервиса: любой программист, разочаровавшийся в языке может себе сделать виртуальный памятник:
Php v3 — v5.3. RIP
У php многое от шаблонизатора, а меня завтра будет хорошее настроение, и много минусов )))
Как идея сервиса: любой программист, разочаровавшийся в языке может себе сделать виртуальный памятник:
Php v3 — v5.3. RIP
Хорошо, когда авторы пишущие о программирование вначале предупреждают: «Я не программист». можно с чистой совестью дальше не читать.
Эм… вот честно — в кой-то веки — ниасилил.
Интерес пропал после 'PHP-шаблонизатор'.
Автор, а у меня PHP используется как источник данных и с JS я с ним общаюсь только по API (гоняю табличные данные JSON-ом (аля REST)) а потом уже отображаю средствами стека JS/HTML/CSS, какая тут к чертовой бабушке шаблонизация? — в исходном постулате автор уже заблуждается.
А еще пару лет назад у меня был мегабайтный скрипт для PHP-CLI для развертывания кластера приложения — тоже никакого отношения к шаблонизации, вот беда-то.
Интерес пропал после 'PHP-шаблонизатор'.
Автор, а у меня PHP используется как источник данных и с JS я с ним общаюсь только по API (гоняю табличные данные JSON-ом (аля REST)) а потом уже отображаю средствами стека JS/HTML/CSS, какая тут к чертовой бабушке шаблонизация? — в исходном постулате автор уже заблуждается.
А еще пару лет назад у меня был мегабайтный скрипт для PHP-CLI для развертывания кластера приложения — тоже никакого отношения к шаблонизации, вот беда-то.
Эмм… Смысл в гибкости, веб-девелопинг очень быстро меняется и монолитный гигантский комбайн вряд ли сможет конкурировать с гибкими решениями как на win, так и на *nix-технологиях (которые вполне себе конкурируют между собой незаметно для конечного пользователя), а иногда и на совсем экзотике, в том числе и embedded, где особо не развернёшься. X.org/rdp — не вариант хотя бы потому, что требования к серверам вырастут на порядки. И вообще, php не так плох и вполне справляется с задачами в своей нише. Flash/actionscript, кстати, не были настолько гибкими и у них была ровно 1 реализация, дыры в безопасности которой до сих пор регулярно исправляют, одного этого факта вполне достаточно, чтобы ограничить их применение.
//зря читал до конца.
//зря читал до конца.
Прочитал до конца. Всю статью можно было уместить в пару тройку предложений и ничего бы абсолютно не изменилось…
Ломающие новости. Ждём цикл статей «Delphi умер», «Вендекапец» и т.д.
Не знаю, правильно ли, но кое-что из текста я понял:
— автор нифига не учился на программиста, поэтому не знает о принципах абстракций (иначе что за http over tcp over ip over ethernet?), поясню: реально в вебе используются 3 стека технологий — технологии канала передачи данных (сеть, и там, кстати, ip не обязательно over ethernet), технологии генератора контента (backend) и технологии визуального отображения контента (frontend). Так много? Далее — тех уникумов, которые реально способны полностью освоить все три стека нет, но это и не требуется, так как есть эти самые абстракции. Они требуют некоего минимального уровня понимания и всё. Кстати сетевой стек штука интересная, http — 6ой уровень в модели OSI (если я правильно помню).
— автору безумно не хватает единого контекста в php (мне тоже не хватает, особенно после того как я вблизи познакомился с java), в котором будут храниться настройки между запросами. Только он не знает как это выразить чётко, поэтому и развёл воду.
— автор неправильно понимает термин «шаблонизатор».
— автор нифига не учился на программиста, поэтому не знает о принципах абстракций (иначе что за http over tcp over ip over ethernet?), поясню: реально в вебе используются 3 стека технологий — технологии канала передачи данных (сеть, и там, кстати, ip не обязательно over ethernet), технологии генератора контента (backend) и технологии визуального отображения контента (frontend). Так много? Далее — тех уникумов, которые реально способны полностью освоить все три стека нет, но это и не требуется, так как есть эти самые абстракции. Они требуют некоего минимального уровня понимания и всё. Кстати сетевой стек штука интересная, http — 6ой уровень в модели OSI (если я правильно помню).
— автору безумно не хватает единого контекста в php (мне тоже не хватает, особенно после того как я вблизи познакомился с java), в котором будут храниться настройки между запросами. Только он не знает как это выразить чётко, поэтому и развёл воду.
— автор неправильно понимает термин «шаблонизатор».
Я понимаю, что php используется преимущественно в веб-разработке, но если бы мне нужно было написать какую-то тулзу для исполнения в терминале, я бы написал ее на php
Работает велосипед, пусть работает. Если на шаблонизаторе можно фейсбук написать, то пусть пишут. Вот лишь-бы придраться к чему-то. Сделайте лучше.
<didnot_read_article_mode on />
<standard_reply_mode on />
<didnot_read_article_mode on />
<standard_reply_mode on />
Неплохой генератор текста у Автора. Яндекс не забанит.
Посыл про нагромождение технологий понял. В принципе от части с вами согласен, но выхода не вижу.
Из поста не понял, почему вы так не любите PHP но любите Python? У меня любов к Python после PHP появилось по многим другим причинам, но вашей не любви я не понял. Почти во всей аргументации можно заменить PHP на Python.
Те же фрймворки на Python не абы какие простые, при всей их «гибкости» и не абы какой широкой функциональности.
Особенно можно поругать ORM SQLAlchemy за сложность её освоения. Особенно они перемудрили в отношениях, где одна сущность ничего не должна знать про другую. И главное, без штудирования документации там никуда. Код никаким образом не говорит как с ним работать.
И ведь в Python, на сколько я знаю, аналогов то и нет.
И все же PHP не велосипед, смотря на результат я могу сделать вывод, что это инструмент для привлечения малоквалифицированных кадров в бизнес разработку.
Из поста не понял, почему вы так не любите PHP но любите Python? У меня любов к Python после PHP появилось по многим другим причинам, но вашей не любви я не понял. Почти во всей аргументации можно заменить PHP на Python.
Те же фрймворки на Python не абы какие простые, при всей их «гибкости» и не абы какой широкой функциональности.
Особенно можно поругать ORM SQLAlchemy за сложность её освоения. Особенно они перемудрили в отношениях, где одна сущность ничего не должна знать про другую. И главное, без штудирования документации там никуда. Код никаким образом не говорит как с ним работать.
И ведь в Python, на сколько я знаю, аналогов то и нет.
И все же PHP не велосипед, смотря на результат я могу сделать вывод, что это инструмент для привлечения малоквалифицированных кадров в бизнес разработку.
> Особенно можно поругать ORM SQLAlchemy за сложность её освоения. Особенно они перемудрили в отношениях, где одна сущность ничего не должна знать про другую. И главное, без штудирования документации там никуда. Код никаким образом не говорит как с ним работать.
Ну… В качестве оправдания могу сказать, что из PHP мира даже доктрина более ужасна, а остальное вообще за гранью добра и зла. «Лично для себя» пришел к странному гибриду django models (даже для non-django projects) и моделей из raw sql.
>И ведь в Python, на сколько я знаю, аналогов то и нет.
Storm, django models, велосипеды в конце концов :)
У питона лично для меня есть решающий плюс по сравнению с PHP. Нет, это даже не синтаксический сахар. Это pip, в котором у большинства модулей вменяемый интерфейс, подробная документация и репозиторий на гитхабе. Pear по сравнению с ним просто ужасен… да и кому нужен pear, когда вся культура PHP-программирования пропитана духом «Not Invented Here»?
Тем не менее, послений проект, в котором я принимаю участие, сделан на PHP и никаких проблем с этим не испытываю. В конце концов, фреймворки, библиотеки и прочая обвязка — это зачастую даже не четверть проекта, а бизнес-логику (гонять массивы туда-сюда и передавать их в запросы) однохренственно на чем писать.
P.S: а вот по отношению к яваскрипту у меня с каждым годом раздражение все крепнет… Язык, в котором лично мне отвратительно абсолютно всё, кроме, возможно, системы областей видимости переменных. Но это уже совсем другая история.
Ну… В качестве оправдания могу сказать, что из PHP мира даже доктрина более ужасна, а остальное вообще за гранью добра и зла. «Лично для себя» пришел к странному гибриду django models (даже для non-django projects) и моделей из raw sql.
>И ведь в Python, на сколько я знаю, аналогов то и нет.
Storm, django models, велосипеды в конце концов :)
У питона лично для меня есть решающий плюс по сравнению с PHP. Нет, это даже не синтаксический сахар. Это pip, в котором у большинства модулей вменяемый интерфейс, подробная документация и репозиторий на гитхабе. Pear по сравнению с ним просто ужасен… да и кому нужен pear, когда вся культура PHP-программирования пропитана духом «Not Invented Here»?
Тем не менее, послений проект, в котором я принимаю участие, сделан на PHP и никаких проблем с этим не испытываю. В конце концов, фреймворки, библиотеки и прочая обвязка — это зачастую даже не четверть проекта, а бизнес-логику (гонять массивы туда-сюда и передавать их в запросы) однохренственно на чем писать.
P.S: а вот по отношению к яваскрипту у меня с каждым годом раздражение все крепнет… Язык, в котором лично мне отвратительно абсолютно всё, кроме, возможно, системы областей видимости переменных. Но это уже совсем другая история.
Ну… В качестве оправдания могу сказать, что из PHP мира даже доктрина более ужасна, а остальное вообще за гранью добра и зла.
Можно пример. На мой взгляд, некоторые вещи в Doctrine сделаны получше.
С остальным с вами полностью согласен.
В современном PHP-мире сейчас вовсю используется composer вместо pear.
Спасибо. Я не «не люблю» PHP. К нему у меня «тёплые ламповые» чувства. А питон я ещё не успел полностью полюбить, но с его бортовым интерпретатором меня посещают гораздо более глубокие «тёплые ламповые» чувства со спектрушных времён. Но я именно «не люблю» пустую, никому не нужную работу, даже если это работа компа, а уж тем более, не люблю делать её сам.
Один мой знакомый сферический конь подсказывает глупый сферический пример: Вам нужно посчитать количество 'лайков' на некоторую статью в блоге в течение, скажем, часа после её публикации; фича сразу закладывалась при проектировании, т.е. код продуман и реализован заранее. На питоне, работающем через uwsgi/nginx вы можете в памяти создать набор переменных для счётчика и триггера, чтобы счётчик включать/выключать; потом на каждый запрос вы просто инкрементируете переменную и всё. Опция не критическая, потери результата в случае краха приложения не боимся, а, если боимся, то просто сбрасываем состояние счётчика в базу в любой момент, да хоть после (до) обработки каждого запроса. На пыхе же придётся регулярно дёргать базу на предмет «пора/не пора», «сколько там — увеличить», и, скорее всего, это будет сделано до выдачи результата.
Менее сферический пример: в modx evo чанки хранятся в базе. При создании страницы будет куча запросов к базе за ними при каждом запросе страницы, которые, конечно, прокэшатся, но они всё равно будут. В питоне их можно загрузить в переменные (т.е., в оперативку) один раз при старте движка, и потом при запросах страницы просто слеплять их с текстом прямо из оперативки чуть ли не конкатенацией в финальный результат.
«Пользователи онлайн» во всей полноте на пыхе тоже задачка интересная. :)
Один мой знакомый сферический конь подсказывает глупый сферический пример: Вам нужно посчитать количество 'лайков' на некоторую статью в блоге в течение, скажем, часа после её публикации; фича сразу закладывалась при проектировании, т.е. код продуман и реализован заранее. На питоне, работающем через uwsgi/nginx вы можете в памяти создать набор переменных для счётчика и триггера, чтобы счётчик включать/выключать; потом на каждый запрос вы просто инкрементируете переменную и всё. Опция не критическая, потери результата в случае краха приложения не боимся, а, если боимся, то просто сбрасываем состояние счётчика в базу в любой момент, да хоть после (до) обработки каждого запроса. На пыхе же придётся регулярно дёргать базу на предмет «пора/не пора», «сколько там — увеличить», и, скорее всего, это будет сделано до выдачи результата.
Менее сферический пример: в modx evo чанки хранятся в базе. При создании страницы будет куча запросов к базе за ними при каждом запросе страницы, которые, конечно, прокэшатся, но они всё равно будут. В питоне их можно загрузить в переменные (т.е., в оперативку) один раз при старте движка, и потом при запросах страницы просто слеплять их с текстом прямо из оперативки чуть ли не конкатенацией в финальный результат.
«Пользователи онлайн» во всей полноте на пыхе тоже задачка интересная. :)
phpdaemon, не? :)
> Один мой знакомый сферический конь
Oh shi---
А какой нибудь специально созданный для этого nosql типа там redis или couchdb? А если не боитесь потери то есть memcache…
Товраисч автор, ваш диагноз — незнание/неумение/нежелание/непонимание использовать современные средства и инструменты для веб-разработки, все проблемы исключительно от этого. Вы копаете конкретно не туда и не так.
И именно от этого такая реакция публики :) Ну просто давным-давно прописные для всех истины вам похоже не ведомы…
Oh shi---
А какой нибудь специально созданный для этого nosql типа там redis или couchdb? А если не боитесь потери то есть memcache…
Товраисч автор, ваш диагноз — незнание/неумение/нежелание/непонимание использовать современные средства и инструменты для веб-разработки, все проблемы исключительно от этого. Вы копаете конкретно не туда и не так.
И именно от этого такая реакция публики :) Ну просто давным-давно прописные для всех истины вам похоже не ведомы…
ЗЫ. Я ни в коем случае не хочу обидеть, просто я говорю о реальности.
Подозреваю что автор учил PHP по учебнику PHP3/4 (напомню что 5 версия выпущена в далеком 2004 году (блин вот же недавно вроде :) ))
Подозреваю что автор учил PHP по учебнику PHP3/4 (напомню что 5 версия выпущена в далеком 2004 году (блин вот же недавно вроде :) ))
Я не утверждаю, что этого сделать нельзя. Речь о том, что именно нужно предпринять, чтобы это реализовать. Прикрутить отдельный движок и инкрементировать одну переменную — о да, это одно и то же.
А сложные объекты, которые невозможно сериализовать вы тоже будете хранить в memcached и подобных?
Апофеоз начинается с реализацией «ленивой загрузки» — ведь все же понимают, что этот код может оказаться и неисполненным, так чего его зазря инклудить? Подвоха не чувствуется ещё? Этот код, быть может, никогда и не исполнится, но он написан! И на его написание было потрачено время, силы, нередко и деньги…
Это вин. Вам платят за количество строк что ли?
Посоветовал бы автору заняться сео-копирайтингом. Такое многословие не должно пропадать зря.
Хочется сказать спасибо автору за такой грамотный и красивый текст. Читать легко и приятно. У автора потрясающая способность смотреть на все сверху и критический взгляд. Как правильно сказали выше, в тексте полно мест, над которыми можно спорить часами. Реакция же сообщества, я думаю ожидаема даже для автора (с его-то видением). Каждый нашел в статье по утверждению, с которым он не согласен и поспешил сказать свое веское фи. Хабр, к сожалению, слишком развлекательный для таких статей.
С удовольствием бы прочитал статью как описание характера некоего персонажа. В хорошем развлекательном романе. А вот на Хабре хочется читать что-то более ёмкое, ясное и по-возможности техническое
Я читал и по порядку и по диагонали… Кто прочитал полностью, скажите, я правильно понял: основная мысль, что надо перейти с PHP на Python? Или надо изобрести вообще что-то новое? Просто я отвлёкся на эти велосипеды с жигулями и не понял о чём текст.
Софистика чистой воды
Прочитал. Если я правильно понял, основная мысль в том — что основной стек web (и не только) технологий слишком сложен, изначально создавался для других задач и далеко не всегда красиво решает текущие. С этим нельзя не согласиться, но идеальных вещей не бывает.
Лучше иметь много слоев, каждый из которых решает свою задачу. Пусть не идеально, пусть сложно, но решает, причем довольно большой круг задач. У любого продукта есть какие-нибудь недочеты. В примере про готовые компоненты про сущности Post, User — да, иногда не хватает. Но есть много готовых решений. Конечно, можно в какой-то фреймворк включить готовые решения. Многие так и делают. Но такие решения часто получаются либо очень абстрактными, разобраться с ними иногда сложнее чем написать свое. Либо решения достаточно простые, но чтобы решить конкретную задачу, приходится много всего переопределять, зачастую не без костылей.
Перфекционизм в программировании это хорошо до определенного уровня. Когда я был юным и наивным, многие библиотеки мне казались достаточно кривыми. Я делал свой велосипед, он выглядел прекрасно, но только до первых правок. Сейчас я намного больше доверяю опыту других разработчиков, особенно в новых областях. Если мне что-то не нравится, я пытаюсь разобраться почему. Зачастую оказывается, что проблемы не в кривости решения а в том что оно уже не укладывается в рамки моего восприятия, и нужно менять себя а не пытаться сделать по-своему. Если существующее решение действительно очень кривое, рано или поздно появится альтернатива и со временем вытеснит предыдущее решение.
Лучше иметь много слоев, каждый из которых решает свою задачу. Пусть не идеально, пусть сложно, но решает, причем довольно большой круг задач. У любого продукта есть какие-нибудь недочеты. В примере про готовые компоненты про сущности Post, User — да, иногда не хватает. Но есть много готовых решений. Конечно, можно в какой-то фреймворк включить готовые решения. Многие так и делают. Но такие решения часто получаются либо очень абстрактными, разобраться с ними иногда сложнее чем написать свое. Либо решения достаточно простые, но чтобы решить конкретную задачу, приходится много всего переопределять, зачастую не без костылей.
Перфекционизм в программировании это хорошо до определенного уровня. Когда я был юным и наивным, многие библиотеки мне казались достаточно кривыми. Я делал свой велосипед, он выглядел прекрасно, но только до первых правок. Сейчас я намного больше доверяю опыту других разработчиков, особенно в новых областях. Если мне что-то не нравится, я пытаюсь разобраться почему. Зачастую оказывается, что проблемы не в кривости решения а в том что оно уже не укладывается в рамки моего восприятия, и нужно менять себя а не пытаться сделать по-своему. Если существующее решение действительно очень кривое, рано или поздно появится альтернатива и со временем вытеснит предыдущее решение.
Автор — аццкий сотона!
Автор не тим-лид, не СЕО, не джуниор и не сеньор.
автора на самообеспечение на поприще (дежа вю!) программирования
По-моему «велосипедин» у вас в крови… Абсолютно на любом языке можно быдлокодить и собирать велосипеды. На мой взгляд PHP сейчас превращается в нечто такое:
А вот ваши рассуждения — что-то подобное:
Назвать PHP шаблонизатором — это как вспомнить, что Linux изначально писался как терминальная программа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про кофе и про Web, или почему PHP — велосипед