Наверное это все-таки старость.
Захотелось мне почему-то поговорить о том, каким путем развивается программирование.
Вернее нет, как я со свой скромной колокольни вижу и понимаю этот путь.
Развитие искусственного интеллекта должно рано или поздно свести программирование к простым голосовым манипуляциям и командам. И по идее мы уже сейчас должны двигаться в этом направлении.
Но почему-то мне кажется, что сейчас это не так и мы идем по пути усложнения. Повторюсь, всему виной может быть просто старость и в 18 лет новый язык влетает в голову за неделю, а в 40 — уже за несколько лет.
Я вот сделал список, условно назовем, языков, которые мне приходится пусть не знать досконально, но по крайней мере ознакомиться, чтобы решать довольно таки примитивные задачи по веб разработке.
Итак.
— js
— php
-css
-sass
-less
-smarty
-phenom
-bootstrap
-node.js
-ruby
-gulp
-git
-lavarel
-modx
-bitrix
-opencart
-simpla
-joomla
-wordpress
-symphony
Я понимаю, что прочитав этот список Вы прежде всего пришли в негодование, как можно в один ряд ставить языки, фреймворки, плагины, системы управления контентом, шаблонизаторы, процессоры и препроцессоры и так далее… Но разве так уж важно как мы их называем? Да MODX не отдельный язык, но что его не нужно изучать? У него есть свой синтаксис, свои правила… Это именно то, что мы в обычной жизни называем языком. Да он на PHP, но ни один учебник PHP не пояснит как работают методы pdoFetch, setPlaceholder и так далее. Ведь новый класс в ООП это практически новый тип переменной, о которой никто кроме разработчика не знает. И к стыду очень уважаемого мной MODX, на официальном сайте еще с 2012 года половина информации значится — в разработке.
А в битрикс мы не отправим почту пока не изучим его объектную модель (правда их плюс, что она хоть и сложная, но детально описана), а в opencart можно повеситься с их XML модификаторами файлов (хотя должен признать, что в этой CMS наиболее прозрачно организован MVC). Чтобы приступить к изучению SASS, нужно установить RUBY и ознакомится с его пакетным менеджером, а GULP покажет язык пока мы не изучим команды пакетного менеджера node.js и хотя бы бегло не почитаем о потоках в node. И так далее и так далее, некий снежный ком, заставляющий с красными глазами до 5 утра изучать и изучать что-то новое.
Да, это интересно, но сам путь такой мне кажется ущербным. Если ком нарастает, то по всем физическим законам, он когда-то достигнет критической массы.
И это не призыв что-то менять, потому что призывать нужно только тогда, когда сам видишь верный путь.
А скорее просто мысли. Но не кажется Вам, что многие вещи мы делаем скорее потому, что это «модно», чем потому, что мы реально в них нуждаемся?
Никто еще чтобы поделиться фоткой с другом не пушит ее на гитхаб и дает ссылку на клонирование?))
Вернее нет, как я со свой скромной колокольни вижу и понимаю этот путь.
Развитие искусственного интеллекта должно рано или поздно свести программирование к простым голосовым манипуляциям и командам. И по идее мы уже сейчас должны двигаться в этом направлении.
Но почему-то мне кажется, что сейчас это не так и мы идем по пути усложнения. Повторюсь, всему виной может быть просто старость и в 18 лет новый язык влетает в голову за неделю, а в 40 — уже за несколько лет.
Я вот сделал список, условно назовем, языков, которые мне приходится пусть не знать досконально, но по крайней мере ознакомиться, чтобы решать довольно таки примитивные задачи по веб разработке.
Итак.
— js
— php
-css
-sass
-less
-smarty
-phenom
-bootstrap
-node.js
-ruby
-gulp
-git
-lavarel
-modx
-bitrix
-opencart
-simpla
-joomla
-wordpress
-symphony
Я понимаю, что прочитав этот список Вы прежде всего пришли в негодование, как можно в один ряд ставить языки, фреймворки, плагины, системы управления контентом, шаблонизаторы, процессоры и препроцессоры и так далее… Но разве так уж важно как мы их называем? Да MODX не отдельный язык, но что его не нужно изучать? У него есть свой синтаксис, свои правила… Это именно то, что мы в обычной жизни называем языком. Да он на PHP, но ни один учебник PHP не пояснит как работают методы pdoFetch, setPlaceholder и так далее. Ведь новый класс в ООП это практически новый тип переменной, о которой никто кроме разработчика не знает. И к стыду очень уважаемого мной MODX, на официальном сайте еще с 2012 года половина информации значится — в разработке.
А в битрикс мы не отправим почту пока не изучим его объектную модель (правда их плюс, что она хоть и сложная, но детально описана), а в opencart можно повеситься с их XML модификаторами файлов (хотя должен признать, что в этой CMS наиболее прозрачно организован MVC). Чтобы приступить к изучению SASS, нужно установить RUBY и ознакомится с его пакетным менеджером, а GULP покажет язык пока мы не изучим команды пакетного менеджера node.js и хотя бы бегло не почитаем о потоках в node. И так далее и так далее, некий снежный ком, заставляющий с красными глазами до 5 утра изучать и изучать что-то новое.
Да, это интересно, но сам путь такой мне кажется ущербным. Если ком нарастает, то по всем физическим законам, он когда-то достигнет критической массы.
И это не призыв что-то менять, потому что призывать нужно только тогда, когда сам видишь верный путь.
А скорее просто мысли. Но не кажется Вам, что многие вещи мы делаем скорее потому, что это «модно», чем потому, что мы реально в них нуждаемся?
Никто еще чтобы поделиться фоткой с другом не пушит ее на гитхаб и дает ссылку на клонирование?))
Комментарии: 11
В 40 лет понимать весь этот бардак может и сложно, но 20 лет назад ничего не было и это все выдумывали на ходу и было не так удобно получать все эти знания, как сейчас. А вы тут жалуетесь. Ну и к слову, с каких пор быть инженером должно быть легко? А программирование (нормальное, не формошлепство) — это все таки поиск решений проблем, настоящая инженерная задача, которая требует обширных знаний в различных областях. Это не просто ни разу, но оплачивается соответственно.
Вы правы.
Я и не жалуюсь, так — размышляю.
Немного не соглашусь в том, что программирование это полностью инженерная задача.
Как инженер с двумя высшими физическими образованиями, я могу сравнивать.
Лично мне программирование кажется больше творческой задачей, близкой к искусству. Хотя и параллели с инженерией есть.
Я думаю то, что мне так сложно воспринимать такое море информации наверное еще связано с малым опытом, я занимаюсь этим только чуть более года. Пока что задачи приходится решать неимоверной усидчивостью и терпением.
А до этого только 20 лет назад был небольшой опыт работы с TurboPascal 6.
Я и не жалуюсь, так — размышляю.
Немного не соглашусь в том, что программирование это полностью инженерная задача.
Как инженер с двумя высшими физическими образованиями, я могу сравнивать.
Лично мне программирование кажется больше творческой задачей, близкой к искусству. Хотя и параллели с инженерией есть.
Я думаю то, что мне так сложно воспринимать такое море информации наверное еще связано с малым опытом, я занимаюсь этим только чуть более года. Пока что задачи приходится решать неимоверной усидчивостью и терпением.
А до этого только 20 лет назад был небольшой опыт работы с TurboPascal 6.
Ещё момент, поскольку вы недавно начали заниматься программированием может быть вам будет это полезно хотя вещь то банальная.
В первую очередь стоит изучить принципы на которых строится технология, тогда будет гораздо проще работать с чем то новым, но основанным на тех же принципах.
Например ООП — независимо от языка принципы полиморфизма, инкапсуляции и наследования остаются неизменными, так остается разница только в синтаксисе. Да и синтаксис современных языков практически идентичен, а уж посмотреть какие функции существуют — всегда есть документация.
Зная алгоритмы вы уже будете знать как решается задача — все что останется это подсмотреть как записать решение с помощью нужного языка.
Зная как устроены РСУБД для вас не будет принципиальной разницы в том MySQL это Postgres или MsSQL.
В первую очередь стоит изучить принципы на которых строится технология, тогда будет гораздо проще работать с чем то новым, но основанным на тех же принципах.
Например ООП — независимо от языка принципы полиморфизма, инкапсуляции и наследования остаются неизменными, так остается разница только в синтаксисе. Да и синтаксис современных языков практически идентичен, а уж посмотреть какие функции существуют — всегда есть документация.
Зная алгоритмы вы уже будете знать как решается задача — все что останется это подсмотреть как записать решение с помощью нужного языка.
Зная как устроены РСУБД для вас не будет принципиальной разницы в том MySQL это Postgres или MsSQL.
Спасибо, но не осилил.
Не могу воспринимать информацию когда лектор все время смеется и разговаривает с кем то за кадром на отвлеченные темы.
Попробую еще разок позже.
Не могу воспринимать информацию когда лектор все время смеется и разговаривает с кем то за кадром на отвлеченные темы.
Попробую еще разок позже.
Ну зоопарк технологий плодится по многим причинам. Есть конечно и веяния моды и желание идти в ногу со временем, но по большей части что-то новое появляется тогда когда в старом не хватает функционала или находится другой путь, кажущийся создателю более логичным и удобным.
Что касается человека который будет работать уже с этими технологиями то почему бы не выбрать что-то одно и не работать с ним, так сказать увеличивать глубину а не ширину знаний. Например у вас в списке 6 cms — смысл знать их все? Sass, Less — это одно и то же под разным соусом, только PostCss не хватает. Phenom, Smarty (ещё куча есть шаблонизаторов и для PHP и для JS) — почему не работать с одним? Laravel и Symfony — какую задачу можно решить на одном фреймворке и нельзя на другом? И это вы ещё не окунулись в волшебный мир фронтенда — вот где разнообразие так разнообразие.
Смысл такой: большая часть элементов вашего списка дублирует друг друга, так что можете смело от них отказаться)
Что касается человека который будет работать уже с этими технологиями то почему бы не выбрать что-то одно и не работать с ним, так сказать увеличивать глубину а не ширину знаний. Например у вас в списке 6 cms — смысл знать их все? Sass, Less — это одно и то же под разным соусом, только PostCss не хватает. Phenom, Smarty (ещё куча есть шаблонизаторов и для PHP и для JS) — почему не работать с одним? Laravel и Symfony — какую задачу можно решить на одном фреймворке и нельзя на другом? И это вы ещё не окунулись в волшебный мир фронтенда — вот где разнообразие так разнообразие.
Смысл такой: большая часть элементов вашего списка дублирует друг друга, так что можете смело от них отказаться)
Согласен с Вами полностью.
Очень многое в этом списке дублировано, а кое что я упустил — jquery например.
Но такому дублированию есть к сожалению логическое пояснение — работодатель берет в работу совершенно разные проекты, в том числе и огромное количество уже работающих сайтов. И как вы понимаете, у меня никто не спрашивает, знаю ли я что-то о simpla или bitrix.
Очень многое в этом списке дублировано, а кое что я упустил — jquery например.
Но такому дублированию есть к сожалению логическое пояснение — работодатель берет в работу совершенно разные проекты, в том числе и огромное количество уже работающих сайтов. И как вы понимаете, у меня никто не спрашивает, знаю ли я что-то о simpla или bitrix.
Ну вот, оказывается проблема совсем другого рода. Дело в работодателе а не в неправильном развитии индустрии)
Нет это не старость, «ожидаемый стек» реально уже давно вышел за все разумные пределы, а ведь «клиповость мышления» это всегда плохо с точки зрения повторяемости результата и глубины знаний. Аналогии с инженером же некорректны, от инженера не требуется обширных знаний в различных областях, его знания не устаревают под ноль за несколько лет, наоборот, нередко полученных знаний хватает до самого конца карьеры. Но самое грустное что с ростом стека как то не видно аналогичного роста оценки вознаграждения в виде денежных знаков, сегодня с джуна требуют больше чем 10 лет назад с сеньора.
Ну естественно. Вообще количество информации увеличивается, просто в ИТ сфере это очень заметно, так как происходит гораздо быстрее. Так это логично в виду темпов развития индустрии. Но, как я уже писал, в условиях появления множества идентичных технологий почему бы не остановиться на чем-то одном? Это позволит как раз добиться глубины знаний.
Основная проблема как уже выше озвучили в «вариативности задач». Конечно хорошо если долгосрочные проекты по знакомому стеку технологий, а если «лучшие сайты подешевле оптом на любых cms и фреймворках» (как обычно и бывает, увы).
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.