Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 149
Лучшее лечение — использовать технологии, которые ты знаешь и которые способны решить эту проблему.
Как говорится — лучше отличная реализация и средняя идея, чем средняя реализация и отличная идея.
Как говорится — лучше отличная реализация и средняя идея, чем средняя реализация и отличная идея.
Именно так рассуждают старые пердуны на коболе и Фортране с «четыре пусто» (имени Шелеста, кто учился, вспомнит).
Они писали в 1967 году на Коболе, они писали 1976 году на Коболе, они писали в 1986 году на Коболе, они не писали в 1996 на Коболе, но их срочно позвали писать на коболе в декабре 1999, они писали на Коболе в 2006, они будут писать на Коболе в 2016 году, а все нюфаги с всякими новомодными глупостями вроде Си или Паскаля могут идти дальше.
Они писали в 1967 году на Коболе, они писали 1976 году на Коболе, они писали в 1986 году на Коболе, они не писали в 1996 на Коболе, но их срочно позвали писать на коболе в декабре 1999, они писали на Коболе в 2006, они будут писать на Коболе в 2016 году, а все нюфаги с всякими новомодными глупостями вроде Си или Паскаля могут идти дальше.
Я думаю, вы пропустили в комменте текст «которые способны решить эту проблему».
Понятно, что никому не нужны сферические решения и если решение требует чрезмерно большого кода на коболе, то это не решение.
Понятно, что никому не нужны сферические решения и если решение требует чрезмерно большого кода на коболе, то это не решение.
Тьюринг полнота означает, что на Коболе можно писать хипстерские ведванольные поделки и академические хаскелевские монадические семигрупоиды. Можно одновременно. То есть формально, «способны решить эту проблему».
А дальше вопрос: надо ли старому пердуну переставать писать на коболе и браться за книжку «основы perl»?
А дальше вопрос: надо ли старому пердуну переставать писать на коболе и браться за книжку «основы perl»?
Я знал, что вы скажете про «формально»)
И поэтому сразу написал, что сферические решения никому не нужны.
Особенно не нужны руководителям, которым кобол разработчик простенький http api оценит в 100500 часов работы.
И поэтому сразу написал, что сферические решения никому не нужны.
Особенно не нужны руководителям, которым кобол разработчик простенький http api оценит в 100500 часов работы.
Тьюринг полнота означает что можно реализовать любую вычислимую функцию, но это совершенно не значит, что можно решить любую задачу с реальными ограничениями (память, время реакции, время выисления итп, стоимость разработки ...). По этому не смотря на абсолютную Тьюринг полноту брейнфака на нем не пишут.
Уже давно нет. Достаточно сравнить число программистов во времена кобола и число программистов в других областях. При одинаковой скорости производства кода, очевидно, что другие платформы просто физически больше и разнообразнее.
Насчёт оценок — откуда цифры? Кто считал число строк кода на коболе в проприетарных системах, которые никогда никто, кроме узкого круга сотрудников не видел?
Насчёт оценок — откуда цифры? Кто считал число строк кода на коболе в проприетарных системах, которые никогда никто, кроме узкого круга сотрудников не видел?
У него сильно устаревшие данные
Допустим, что 100% банков работают на 100% кобола. Даже когда на сайте банк-клиента в урле написано isp.dll или jar?..., это тоже кобол.
Предположим, у нас по 1000 банков на страну. Примерно 200 стран. Это 200 000 программ.
Заходим в гугльаппс, смотрим сколько приложений в play, добавляем к этому число приложений в appstore, посыпаем виндами и симбианом, и имеем… Ага?
А теперь открываем список пакетов debian, каталог софта под винды, запускаем стим и смотрим на список игрушек, ищем список интернет-магазинов… Мне список продолжать или нет?
Предположим, у нас по 1000 банков на страну. Примерно 200 стран. Это 200 000 программ.
Заходим в гугльаппс, смотрим сколько приложений в play, добавляем к этому число приложений в appstore, посыпаем виндами и симбианом, и имеем… Ага?
А теперь открываем список пакетов debian, каталог софта под винды, запускаем стим и смотрим на список игрушек, ищем список интернет-магазинов… Мне список продолжать или нет?
Как будто за эти два года что-то существенно поменялось. Банков — мало. На фоне числа сайтов и самопальных движков на всяких php/perl/cgi-bin-на-неизвестном меркнет даже всякий GPlay, а ведь есть десятилетия software индустрии под винды и 30-40 лет геймдева.
Я думаю ему тоже за 2 года до этого кто-то рассказал
Вот интересно, почему на сайтах по поиску работы по запросу «Cobol» пишут: «Не найдено ни одной вакансии — измените параметры поиска»?
В то время как банки размещают вакансии для программистов совсем других языков. C++, Java, C#, ASP.NET,… Но не Cobol
В то время как банки размещают вакансии для программистов совсем других языков. C++, Java, C#, ASP.NET,… Но не Cobol
а вы где ищете? на Монстре 88 вакансий вотпрямщас
Может имелось в виду «больше в сравнении с любым другим языком», а не со всеми вместе взятыми?
Справедливости ради отметим, что сложность кода банковской системы ( часто это миллионы строк кода ) и сложность большинства игрушек в гугл плей несравнима. Т.е. одну банковскую систему нужно сравнивать с сотней игрушек, как минимум.
Что не отменяет, конечно, сомнительность исходного утверждения.
Что не отменяет, конечно, сомнительность исходного утверждения.
А я думал, что все банки на Delphi…
а я то все удивлялся, почему вот тут так стебутся над COBOL программистами. огромное спасибо, что разрешили мое любопытство
Вот тут и есть легкая форма безыходности: как и рыбку съесть, и в воду не лезть…
Часть времени надо тратить на новые технологии, это называется «повышение квалификации».
Вопрос — на какие?
Кто мне ответит — что сдохнет через полгода, а что переживёт хотя бы 5 летний рубеж?
Может кто-то за эти 5 лет создаст убийцу c++ и javascript и html до кучи и все знания языков, которые я знаю можно будет выбросить на помойку, как всякие Paradox (Db была такая в свое время), Фортраны, и Forth'ы.
Вот мне все говорят что Perl сдох, воняет и вообще, не насилуй труп — только почему-то чтобы обновить перл в debian/Ubuntu с 5.14 на 5.20 надо перелопатить perl-base, perl-modules которые до сих пор входят в system-base и так просто не выкусываются.
Кто мне ответит — что сдохнет через полгода, а что переживёт хотя бы 5 летний рубеж?
Может кто-то за эти 5 лет создаст убийцу c++ и javascript и html до кучи и все знания языков, которые я знаю можно будет выбросить на помойку, как всякие Paradox (Db была такая в свое время), Фортраны, и Forth'ы.
Вот мне все говорят что Perl сдох, воняет и вообще, не насилуй труп — только почему-то чтобы обновить перл в debian/Ubuntu с 5.14 на 5.20 надо перелопатить perl-base, perl-modules которые до сих пор входят в system-base и так просто не выкусываются.
На те, к которым лежит душа. Через пять лет устареет примерно половина из них, вторая будет называться «обширный опыт» и им можно будет травить ньюфагов, которые не понимают, почему им это надо учить, но без знания этого не понять эзотерики в новом.
Знания никогда лишними не бывают, а изучение того, что нравится, а не того, что «в тренде» определяет будущую карьеру — она оказывается с тем, что нравится, а не с тем, что «в тренде». Лично для меня это важнее, чем мелкая вариация в цифре зарплаты (наблюдения показывают, что хорошие знания в любом случае ценятся). Возможно кому-то важнее «в тренде» и он учит всё, даже то, что не нравится.
Это уже вопрос личных предпочтений. (Так, например, я полностью отказываюсь разбираться с руби, потому что он мне не нравится — и это совсем не мешает мне быть экспертом в других областях).
Знания никогда лишними не бывают, а изучение того, что нравится, а не того, что «в тренде» определяет будущую карьеру — она оказывается с тем, что нравится, а не с тем, что «в тренде». Лично для меня это важнее, чем мелкая вариация в цифре зарплаты (наблюдения показывают, что хорошие знания в любом случае ценятся). Возможно кому-то важнее «в тренде» и он учит всё, даже то, что не нравится.
Это уже вопрос личных предпочтений. (Так, например, я полностью отказываюсь разбираться с руби, потому что он мне не нравится — и это совсем не мешает мне быть экспертом в других областях).
«Кто мне ответит — что сдохнет через полгода, а что переживёт хотя бы 5 летний рубеж?»
Стараюсь смотреть на технологии, которые как раз пережили трех-пятилетний рубеж.
Это как минимум будет означать что у проекта/технологии есть хорошее сообщество, проект востребован, готов к использованию в production, меньше багов и т.д.
Стараюсь смотреть на технологии, которые как раз пережили трех-пятилетний рубеж.
Это как минимум будет означать что у проекта/технологии есть хорошее сообщество, проект востребован, готов к использованию в production, меньше багов и т.д.
COBOL тоже подходит
Можно и не обновлять общесистемный перл — поставьте себе perlbrew.
Смотря что называть — переживет.
Haskell, Erlang, Rust, R, Julia, Modelica, SPARQL гарантированно будут живы и развиваться через 5 лет. Но врядли будут сильно востребованы на рынке.
Haskell, Erlang, Rust, R, Julia, Modelica, SPARQL гарантированно будут живы и развиваться через 5 лет. Но врядли будут сильно востребованы на рынке.
Это какая-то страшилка, очень далекая от реальности. Последний крупный переход на новые технологии я делал лет 10 назад, с тех пор по чуть-чуть добавляется всякой мелочевки. Да и то, я уверен, что при желании я без проблем нашел бы заказчиков и с теми знаниями десятилетней давности, С/С++ и т.п.
Ну тогда так и говорите: «Возможно уже существует пара компаний, которые пишут для продакшена исключительно на Go им могут быть не нужны прошлые технологии», а не «твои навыки никому не нужны». Согласитесь не совсем одно и то же.
Тут в интернетиках во всю бегала новость о том, что Postgresql уделал nosql по производительности, так что я бы посомневался, стоит ли выбрасывать традиционные SQL
Ага, найдите заказчиков со знаниями 10летней давности по JS.
Ну, в том же C++ свистелок/перделок наплодилось немало — один буст чего стоит
Закон Паркинсона для чиновников: Чиновник получает повышения, пока не займет пост, на котором он будет некомпетентен, и на нем и станется.
Закон Паркинсона для программистов: В любой сложной системе, будет как минимум один компонент, который написан с использованием технологии, которую программист использует в первый раз. Если программист уже имеет опыт работы с аналогичной технологией (например, MySQL или RabbitMQ), проект будет содержать альтернативную технологию (MongoDB и ZeroMQ)
Закон Паркинсона для программистов: В любой сложной системе, будет как минимум один компонент, который написан с использованием технологии, которую программист использует в первый раз. Если программист уже имеет опыт работы с аналогичной технологией (например, MySQL или RabbitMQ), проект будет содержать альтернативную технологию (MongoDB и ZeroMQ)
А потом через пару леть пойти искать новую работу и понять, что твои навыки никому не нужны.Это если хвататься за модные@молодёжные поделия, особенно под веб. Если же уцепиться за стабильно несущийся паровоз .NET или Java платформы — можно ехать на нём до самой пенсии.
А почему на текущей работе вы используете то, что через пару лет будет неактуальным?
Можно предположить, что и со следующей работой выйдет так же, и вот он паралич.
Хотя достаточно лишь чтобы работа позволяла пробовать, экспериментировать, обучаться
Можно предположить, что и со следующей работой выйдет так же, и вот он паралич.
Хотя достаточно лишь чтобы работа позволяла пробовать, экспериментировать, обучаться
Согласен. Я начинал с Java, потом ушел в iOS, потом в Android, потом писал на Scala (да, да) а сейчас ушел в веб. И там начинал с PHP + MySQL а теперь вот начинаю второй проект на MEAN (MongoDB, Express, Angular.js & Node.js). Так что да — мигрируемс…
Может лучше свалить в нишу, где всё меняется помедленнее?
Есть опасность остаться в ней навсегда. И потом в 40-50 лет идти устраиваться джуниором в совершенно другую нишу. Да, опыт не пропьешь, и за полгода можно поменять специализацию, но все же…
(задумался, в какой области «всё меняется помедленнее»)
Так, чтобы не «в принципе, жить можно», а чтобы «модный современный». Ну, пожалуй, водители (которым не надо разбираться в настройках для автопилота) или бухгалтера (у которых постоянно не меняется всё на свете), или хотя бы в развозчики пиццы (которым надо чекаутиться в момент доставки в фирменном приложении), или…
Долго думал, хотел сказать «шаурмячника», вспомнил, что на Кипре у шаурмячников есть специальные болгарки для резьбы мяса, которых я в Питере не видел — и тут прогресс.
В какой профессии у нас не меняется ничего? Пожалуй, очень древнюю профессию в которой ничего не меняется последние лет 50 (с момента изобретения нормальной контрацепции) я назвать могу, но туда трудно «свалить».
Так, чтобы не «в принципе, жить можно», а чтобы «модный современный». Ну, пожалуй, водители (которым не надо разбираться в настройках для автопилота) или бухгалтера (у которых постоянно не меняется всё на свете), или хотя бы в развозчики пиццы (которым надо чекаутиться в момент доставки в фирменном приложении), или…
Долго думал, хотел сказать «шаурмячника», вспомнил, что на Кипре у шаурмячников есть специальные болгарки для резьбы мяса, которых я в Питере не видел — и тут прогресс.
В какой профессии у нас не меняется ничего? Пожалуй, очень древнюю профессию в которой ничего не меняется последние лет 50 (с момента изобретения нормальной контрацепции) я назвать могу, но туда трудно «свалить».
Ага, например стать плотником? Или что-то поновее, например, сварщиком?
1. Изучать надо не языки и фреймворки, а подходы и концепции. Если вы знаете Python, то перейти на Ruby будет несложно. Если вы умеете оптимизировать запросы в Oracle, то и в PostgreSQL сможете найти узкие места. Не нужно быть экспертом в каждой технологии, нужно хорошо понимать идеи, на которых они основаны.
2. Зачем такой винегрет названий? Зачем бекендщику разбираться в фреймворках для iOS, а фронендщику знать разницу между AWS и GAE? Есть масса техногий и направлений, о которых в статье даже не упомянули (например, программирование микроконтроллеров, аналитические базы данных на сотни терабайт, обработка изображений, искусственный интеллект...), но о них действительно должны знать все разработчики вне зависимости от специализации?
2. Зачем такой винегрет названий? Зачем бекендщику разбираться в фреймворках для iOS, а фронендщику знать разницу между AWS и GAE? Есть масса техногий и направлений, о которых в статье даже не упомянули (например, программирование микроконтроллеров, аналитические базы данных на сотни терабайт, обработка изображений, искусственный интеллект...), но о них действительно должны знать все разработчики вне зависимости от специализации?
Угу. Только про конвертируемость технологий работодателям рассказать забыли. Если вы 10 лет писали на Python и решили отправить своё резюме на вакансию Ruby-разработчика, девочка HR будет считать, что у вас опыт отсутсвует вообще.
Какую-то неправдоподобную ситуацию вы обрисовали. Во-первых, если вы 10 лет писали на Python, а потом зачем-то резко решили перейти на Ruby, то наверное вы как минимум интересовались этим языком, пытались что-то на нём делать, пусть даже и не в коммерческом проекте. Во-вторых, если девочка HR смотрит на разработичка с 10-летним опытом как на полного джуниора в новой для него области, то гнать такую девочку взашей. Потому что нормальный HR должен понимать, что кроме языка программирования есть ещё масса междисциплинарных навыков (архитектура, алгоритмы, сеть и т.д.), которые часто оказываются гораздо важнее знания очередного набора ключевых слов.
Джуниором на руби после 10 лет питона вас, вероятно, возьмут.
Но именно что джуниором.
Но именно что джуниором.
Так я как раз и говорю, что расценивать такого человека как джуниора только потому, что он писал на другом языке, — абсолютно неправильно. Я и собеседовался, и собеседовал людей на позиции с совершенно новыми для них технологиями, но если у человека был хороший общий бекграунд в информатике (или, как это модно сейчас называть, computer science), то буквально за 2 недели он начинал писать вполне годный код на новом языке.
У людей, которые постоянно изучают новые языки, есть даже такая привычка: на каждом новом языке пытаться написать какую-то задачу (например, чат или напоминалку). При переходе на новый язык они просто ищут аналоги уже знакомых библиотек (http сервер, библиотекаа логгирования, парсер регулярных выражений и т.п.), и очень быстро получают хорошее понимание основ языка.
У людей, которые постоянно изучают новые языки, есть даже такая привычка: на каждом новом языке пытаться написать какую-то задачу (например, чат или напоминалку). При переходе на новый язык они просто ищут аналоги уже знакомых библиотек (http сервер, библиотекаа логгирования, парсер регулярных выражений и т.п.), и очень быстро получают хорошее понимание основ языка.
Одна маленькая проблема: типичный работодатель/HR — не вы, а так всё верно, никто ж с вами и не спорит :-)
Точно. Как раз недавно думал об этом. Возможно, для особо ценных специалистов это иначе, но для миддлов у меня создалось как раз такое ощущение, что типичному работодателю мало интересны абстрактные подходы и концепции, его интересуют конкретно вещи, на которые он нанимает. Даже после прохождения HR. Особенно, если это не Python -> Ruby и не Java -> C#, а Ruby -> C или JavaScript/Ruby -> Java. Такой опыт похоже вообще не рассматривается как какой-то релевантный.
Особенно, если это не Python -> Ruby и не Java -> C#, а Ruby -> C или JavaScript/Ruby -> Java
А вот это уже как раз относится к подходам и концепциям. Ruby — высокоуровневый, динамический, объектно-ориентированный, C — низкоуровневый, статический, процедурный. Точно так же JavaScript/Ruby — это мир веб-разработки, сайтов, богатого фронт-енда, Java — жёсткий бекенд и толстых корпоративных приложений. Опыт в одной области слабо коррелируюет с опытом в другой. Настоящий вопрос здесь — почему вам, собственно, захотелось так сильно изменить область?
Ну, замените в моём комментарии слово Python на Perl, и получите примерно мою ситуацию. На большинство вакансий, даже самых унылых и низкооплачиваемых, работодатели хотят 3+ лет опыта.
Хм, вам, конечно, виднее, но я всё равно слабо представляю, как так получается на практике. Возьмём наугад вакансию Python разработчика: в требованиях один пункт касается непосредственно Python, остальное — работа с БД, очереди сообщений, многопоточность и отказоустойчивость. Общий опыт работы — 1..3 года. Неужто 1..3 года знакомства с синтаксисом языка перевешивает для работодателя знание всей остальной инфраструктуры и опыт построения сложных систем? Если действительно так, и если работодатель (или, скорее всего, тим лид/менеджер) настолько технически и управленчески неграмотен, чтобы не понимать ситуацию, то и смысл идти в такую компанию, а потом каждый день натыкаться на плохие решения?
Насчет перл, как раз таки контрпример: Booking.com задолбались искать перловиков и последние несколько лет хантят php-разработчиков с последующим «перевоспитанием». Ибо руки им нужны а свободных на рынке как бы нет. Так что не все так плохо в датском королевстве.
Смотря где и как. У меня была подобная ситуация. Около 10 лет на php, меня через знакомых вытаскивали на вакансию python разработчика. Сам работодатель. Сразу давая время на «обучение», за которое я буду получать такую же ЗП как и потом. Без испытательного срока. В итоге уговорили перейти к ним.
Загвоздка крылась в том, что нужен был разработчик в штат. А специализация в городе не развита вообще. Есть единицы, но переманить не реально. Или же знания шапочные, а в самой сфере вообще отсутствуют. И выбор был отдан в сторону переобучения, но большим опытом и знаниям в сфере (веб разработка), а не языку.
З.Ы. Обучение было официально 2 месяца. Освоился более менее в языке за две недели. Дальше наращивание умений и опыта. Но через 2 недели, уже мог решать рабочие задачи, пускай и мелкие.
Загвоздка крылась в том, что нужен был разработчик в штат. А специализация в городе не развита вообще. Есть единицы, но переманить не реально. Или же знания шапочные, а в самой сфере вообще отсутствуют. И выбор был отдан в сторону переобучения, но большим опытом и знаниям в сфере (веб разработка), а не языку.
З.Ы. Обучение было официально 2 месяца. Освоился более менее в языке за две недели. Дальше наращивание умений и опыта. Но через 2 недели, уже мог решать рабочие задачи, пускай и мелкие.
Согласен с Вами.
Вот мне, сейчас после C# + Asp.Net MVC + MS SQL писать небольшой проект на Perl + Mojolicious + PostgreSQL — одно сплошное удовольствие.
Подход, по сути один же. Языки… ну есть отличия и ньюансы в конструкциях языков, но логика — ОДНА, да и основные конструкции мало отличаются — присвоение, if/else, математика — она во всех языках одинакова
Вот мне, сейчас после C# + Asp.Net MVC + MS SQL писать небольшой проект на Perl + Mojolicious + PostgreSQL — одно сплошное удовольствие.
Подход, по сути один же. Языки… ну есть отличия и ньюансы в конструкциях языков, но логика — ОДНА, да и основные конструкции мало отличаются — присвоение, if/else, математика — она во всех языках одинакова
Почему же не избавляет? Если вы знаете, как работают технологии, то скорее всего понимаете их преимущества и недостатки, а значит можете выбрать ту, которая лучше всего подходит для вашего проекта. Конечно, какое-то время всё-равно придётся потратить, но это уже время на оценку и пристреливание, а не на детальное изучение.
Но ведь если вы один раз выберете между Zk, etcd и прочими, то второй раз вам это делать не придётся, верно? Т.е. вы уже определитесь, с каким сервером конфигураций вам удобней работать, и в следущем проекте такого вопроса стоять уже не будет. Затем появится ещё один инструмент, затем ещё, и в итоге у вас будет хороший, проверенный список инструментов, а вам нужно будет только выбрать подходящий.
Почему вас беспокоят эти технологии?
Вам в магазине не приходит в голову, что выбор из двух десятков названий молока — это проблема. Либо у вас есть понимание какое молоко вы пьёте (непастеризованное, импортное, фермерское) и вы быстро определяетесь со списком, из которого берёте то, что ближе, либо просто берёте то, что ближе.
Вы же не задумываетесь как там плодятся проекты пакетиков с новыми сортами молока.
Вам в магазине не приходит в голову, что выбор из двух десятков названий молока — это проблема. Либо у вас есть понимание какое молоко вы пьёте (непастеризованное, импортное, фермерское) и вы быстро определяетесь со списком, из которого берёте то, что ближе, либо просто берёте то, что ближе.
Вы же не задумываетесь как там плодятся проекты пакетиков с новыми сортами молока.
Как кто-то остроумно сказал: Знание некоторых принципов компенсирует незнание многих фактов.
Не санскрит, а китайский. Пусть не через 5 лет, а через 10-15, но станет.
Пусть будет оффтоп, но по моему мнению экономика Китая держится на огромной девальвации своей рабочей силы — отсюда приток технологий и рабочих мест в Китай. Сами они, без запада и Японии с Кореей, опять же по моему мнению, неминуемо опустятся до уровня эпохи Мао.
Мы не в сферическом вакууме живём, во-первых. Поэтому ни Япония, ни Корея, ни запад никуда не денутся. Во-вторых, Китай потихоньку наращивает своё благосостояние, даже на данный момент китайская рабочая сила уже дороже, чем в 80-х — 90-х. Что-то не видно, как с удорожанием рабочей силы и повышением уровня жизни Китай скатывается в эпоху Мао.
Зато видна другая тенденция — производство айфонов уже вывели из Китая в США.
Вы что-то слышали, но не потрудились разобраться.
Айфоны как собирала Фоксконн в Китае, так и продолжает собирать. Эпл просто развернула их производство ещё и на тайваньском заводе. Вполне логичный шаг, устройств уже много — iPod, iPhone, iPad, часы скоро тоже начнут производить, так что компания наращивает производственные мощности. В США пока Эпл айфоны не производит, только собирается открыть фабрику по производству чипов (в том числе и процессоров). Но чипы для Эпл Китай никогда и не делал, этим занималась Самсунг в Корее.
Айфоны как собирала Фоксконн в Китае, так и продолжает собирать. Эпл просто развернула их производство ещё и на тайваньском заводе. Вполне логичный шаг, устройств уже много — iPod, iPhone, iPad, часы скоро тоже начнут производить, так что компания наращивает производственные мощности. В США пока Эпл айфоны не производит, только собирается открыть фабрику по производству чипов (в том числе и процессоров). Но чипы для Эпл Китай никогда и не делал, этим занималась Самсунг в Корее.
Отлично знаешь только С++, пиши только на С++.
В C#, к примеру, появляются такие фишки как linq, async-и, новые фреймворки (как то ранее использовался WebForms, потом MVC, сейчас MVC+Angular). То есть тот C#, который был в 2005, сильно отличается от современного.
Насколько я понимаю, подобная ситуация и с C++ (хотя давно не использовал). Язык почти не изменился, однако изменились подходы, появились новые фреймворки… Ранее использовали MFC, теперь пересели на qt.
Для справки, язык С++ таки сильно изменился. Во-первых, новомодные лямбды, auto и range for радикально меняют облик программ, до нечитаемости для впавшего в 10-летний сон программиста. Во-вторых, во времена MFC народ даже STL не использовал во многих реальных проектах (привет, CString vs std::string), а сейчас без бутстрапа или qt никуда — а это опять же изменение облика программ до нечитаемости.
В прошлом году занесло меня в очередной конкурс интел, требования были — C#/WPF/NET. Я раньше писал на C#, но WPF видел впервые. Пришлось потратить две недели на изучение новых фишек. При этом я относился к этому по остаточному принципу, так как было много своей основной работы — кодил дома по вечерам. Так вот это реально, просто надо потратить время, расшевелить мозг. Важна мотивация. если вам интересна новая работа или технология, время найти можно на ее изучение. Думаю два месяца более упорного изучения и можно стать мидллом в данной теме, если есть какой-то иной опыт разработки.
А то, что вы изучаете что-то новое это, на мой взгляд, большой плюс нашей области. просто с возрастом мы инертные становимся и это не дает нам окончательно деградировать. Но это мое большое имхо, конечно.
Ну в формах и wpf разница то не большая грубо говоря, а уж сам C# везде одинаковый. Было бы интересно узнать опыт быстрого перехода с C# на java хотя бы)
Лекарство от этой болезни есть — нужно просто уходить в свой бизнес или инвестирование. Онлайн, оффлайн — любое на что хватает средств и знаний. Конечно, в этом тоже нужно следить за трендами, но не с такой скоростью.
В посте идея «хочу все знать и уметь» (хотя на самом деле не все, а то, о чем вы встречаете упоминания).
И в комментах очень странный аргумент — «если не учить все-все-все, через пять лет ваши знания устареют».
Как будто вы программируете свою жизнь на пять лет вперед и дальше включаете автопилот.
Между «сейчас» и «через пять лет» у вас есть целых пять лет на даже простое чтение новостей и отслеживание трендов.
Ну и не понятна идея с «вас уделает ниндзя».
Всегда будут люди, которые программируют хуже вас и которые программируют лучше вас.
И в среднем по больнице, и в каждой специализации.
Если вы страдаете от этой мысли, то… паралич в голове, а не в программировании.
И в комментах очень странный аргумент — «если не учить все-все-все, через пять лет ваши знания устареют».
Как будто вы программируете свою жизнь на пять лет вперед и дальше включаете автопилот.
Между «сейчас» и «через пять лет» у вас есть целых пять лет на даже простое чтение новостей и отслеживание трендов.
Ну и не понятна идея с «вас уделает ниндзя».
Всегда будут люди, которые программируют хуже вас и которые программируют лучше вас.
И в среднем по больнице, и в каждой специализации.
Если вы страдаете от этой мысли, то… паралич в голове, а не в программировании.
Год или два назад на хабре проскакивал пост от разработчиков, где они писали, что придерживаются принципа «не больше одной новой технологии в каждом новом проекте», или что-то похожее. Мне кажется, это наиболее оптимальный путь.
Автор оригинальной заметки путает понятия «инструмент» и «подход».
Инструмент может быть любой. Подход от изменения инструмента не меняется кардинально. Когда-то топор был из обструганной палки и привязанного камня. Сейчас — облегченное углепластиковое топорище и лезвие из стали особой марки. В подходе что-то кардинально поменялось? Да, изменились трудозатраты при использовании инструмента. Но подход: «руби», не изменился.
Грубая аналогия, но, надеюсь, мысль понятна.
Инструмент может быть любой. Подход от изменения инструмента не меняется кардинально. Когда-то топор был из обструганной палки и привязанного камня. Сейчас — облегченное углепластиковое топорище и лезвие из стали особой марки. В подходе что-то кардинально поменялось? Да, изменились трудозатраты при использовании инструмента. Но подход: «руби», не изменился.
Грубая аналогия, но, надеюсь, мысль понятна.
Численные методы и интегральное счисление не поменяются (разве что математики придумают что-то реально новое). Я это имею в виду. База всегда одна и та же.
Что в игле, что в альтиуме или оркаде, я сделаю плату и она будет работать, если я обладаю базовыми знаниями, как должно быть. Весь вопрос в трудозатратах и удобстве разработки.
Что в игле, что в альтиуме или оркаде, я сделаю плату и она будет работать, если я обладаю базовыми знаниями, как должно быть. Весь вопрос в трудозатратах и удобстве разработки.
Мда. Пытался написать развернутый ответ, но в итоге всё можно свести к одной мысли: база есть всегда, рюшечки преходящи.
А все эти метания «ах, что же выбрать из зоопарка технологий и инструментов» всего лишь проявление прокрастинации. Когда вместо непосредственного выполнения работы задаешься вопросом, как бы эту самую работу сделать еще более эффективно.
А все эти метания «ах, что же выбрать из зоопарка технологий и инструментов» всего лишь проявление прокрастинации. Когда вместо непосредственного выполнения работы задаешься вопросом, как бы эту самую работу сделать еще более эффект
Представьте, что на своей старой работе вы застряли в каком-нибудь оркаде 8, и, наконец, решили сменить работу на ту, где хотят альтиум 14. Вам как минимум пару месяцев придется изучать новый интерфейс (хотя вы и знаете, что в итоге нужно получить). Вопрос в том, кто будет оплачивать эти пару месяцев вашего вынужденного простоя.
А теперь представьте, что сменился не только интерфейс программы, но и тип логики (скажем КМОП вместо ЭСЛ), и, заодно, степень интеграции заметно подросла. Т.е. вам еще придется отвыкать пихать везде или-не и переходить на и-не.
А теперь представьте, что сменился не только интерфейс программы, но и тип логики (скажем КМОП вместо ЭСЛ), и, заодно, степень интеграции заметно подросла. Т.е. вам еще придется отвыкать пихать везде или-не и переходить на и-не.
В численных методах многое поменялось. Упор делается на параллельную обработку, использование FPGA, GPGPU.
Что-то удобнее писать на функциональных языках, а что-то нет. А вообще, оно чуть ли не древнее объектно-ориентированного — с шестидесятых годов вообще мало что принципиально нового придумали. Развели кашу из фрэймворков — это да, нет одного центра, который бы качественно делал стэк (как, например, у Apple с iOS). Все, кому не лень, придумывают новые фрэймворки и тулкиты разной степени говнистости, на 90% дублирующие друг друга и каждый со своим обширным набором багов.
Технологическая сигулярность начинает развиваться и действовать. Страшно думать иногда о таком, кстати.
Эффект Эффект Даннинга — Крюгера в программировании. Отличные разработчики переживают, что они не успевают осиливать все технологии, а обычные кодеры годами ваяют на 1С одном языке программирования и считают себя суперкрутыми спецами.
По большей части я просто чувствую вину за то, что не делал ничего на
вы будете жить в постоянном страхе, что какой-нибудь ниндзя-программист на
Проблема, как обычно, в голове. Я должен знать и уметь все (не получается -> чувство вины) чтобы быть лучше всех (не получается -> задето ЧСВ). Любой доктор бы посмеялся с этих проблем.
Старая добрая специализация.
Активно слежу за многообразием инструментов (что достаточно удобно благодаря Хабру), но осваивать все нет ни сил, ни времени. При начале нового проекта вспоминаю про примелькавшиеся новые инструменты, и если что-то из них оказывается кстати, пытаюсь применить. Чем менее критичный проект, тем больше позволяю себе экспериментировать.
Главное найти баланс. Использование старых привычных инструментов достаточно предсказуемо, качества кода и скорость разработки выше, реже приходится прибегать к рефакторингу. Но при этом становится скучно, мозги начинают заплывать жиром, постепенно понижается конкурентоспособность. Новые инструменты решают задачи быстрее и красивее, играться новыми подходами интересно. Но на первых этапах освоения приходится смириться с пониженной скоростью разработки с менее эффективным кодом, который скорее всего придется рефакторить по мере освоения инструмента.
Главное найти баланс. Использование старых привычных инструментов достаточно предсказуемо, качества кода и скорость разработки выше, реже приходится прибегать к рефакторингу. Но при этом становится скучно, мозги начинают заплывать жиром, постепенно понижается конкурентоспособность. Новые инструменты решают задачи быстрее и красивее, играться новыми подходами интересно. Но на первых этапах освоения приходится смириться с пониженной скоростью разработки с менее эффективным кодом, который скорее всего придется рефакторить по мере освоения инструмента.
Пробовать что-то новое можно дома в свободное время. На работе времени на новое остаётся мало: там дедлайны, требования, сертификации. Что-то новое использовать сразу сложно, если ты работаешь не над каким-то стартапом. Так что этот паралич лечится просто работой в компании покрупнее
Когда научился программировать, я понял, что смогу программировать на любом языке, поняв лиш его логику (это не то же самое, что разобраться в коде других людей), по-этому я не заморачиваюсь, а просто программирую на том, на чем могу и умею сейчас.
Наверно всё-таки в этой статье ужасы сильно преувеличены.
У меня возраст в программировании около 25 лет, и описанная проблема раньше вставала передо мной с завидным постоянством.
Поначалу был уверен в идее «вот сейчас выучу самый крутой язык и можно будет больше не учиться и спокойно работать».
Сначала это был паскаль, потом си, потом с++, потом пошли ветвления — Oracle SQL, perl, диалекты и фреймворки (ASP, MFC, STL, boost и т.д. и т.п.)
Каждый раз я был уверен, что вот уже теперь-то можно отдохнуть и больше не чувствовать себя нубом.
Особенно сильно такое ощущение было во время изучения с++.
Но потом такой подход («надо выбрать самый крутой язык и больше ничего не смотреть») постепенно поменялся на другой («для новой задачи возможно есть что-то, что позволит решить её легче»).
Так после краткого периода под лозунгом «всё, устал от этой гонки, не вижу ничего, пишу на с++» осмотрелся и для задач обсчета больших массивов данных изучил R и python.
И это очень понравилось — использовать удобный инструмент с его особенностями, заточенными под класс задач.
Да, можно написать и на с++, но трудозатраты не сравнимы, если нужно быстро что-то набросать.
Поэтому мне кажется, что для выхода из этого паралича нужно идти от задачи.
Если есть что-то, что позволит значительно облегчить разработку и получить качественный результат, то это стоит изучить.
Формула озвучена в известном мультфильме про крылья и ноги:
затраты_на_разработку_старым_инструментом > затраты_на_изучение_нового_инструмента + затраты_на_разработку_новым_инструментом
Под затратами_на_разработку_* надо, конечно, понимать суммарные на протяжении всего периода использования, а не только в новом отдельно взятом проекте.
В опровержение или, скорее, уточнение проскочившей вверху идеи, что надо только освоить основополагающиее принципы, а дальше будет легко писать на чём угодно, хотел бы сказать следующее.
Как мне кажется, переход на другой инструмент (если он не мотивирован просто оргштатными мероприятиями) позволит получить выгоду только в том случае, если будут использоваться его особенности.
Для примера — на питоне можно писать как на любом другом языке с использованием только операторов присваивания, математических, ветвления, циклов и т.д.
Но если не использовать comprehension, то не получишь ни ускорения в работе, ни ускорения в коде, ни кайфа от красиво решенной проблемы.
Так что переход на другой язык требует его изучения.
Невозможно пользоваться только core features и получать полную отдачу от освоенного языка/библиотеки/фреймворка/…
Надеюсь, написал по делу :)
У меня возраст в программировании около 25 лет, и описанная проблема раньше вставала передо мной с завидным постоянством.
Поначалу был уверен в идее «вот сейчас выучу самый крутой язык и можно будет больше не учиться и спокойно работать».
Сначала это был паскаль, потом си, потом с++, потом пошли ветвления — Oracle SQL, perl, диалекты и фреймворки (ASP, MFC, STL, boost и т.д. и т.п.)
Каждый раз я был уверен, что вот уже теперь-то можно отдохнуть и больше не чувствовать себя нубом.
Особенно сильно такое ощущение было во время изучения с++.
Но потом такой подход («надо выбрать самый крутой язык и больше ничего не смотреть») постепенно поменялся на другой («для новой задачи возможно есть что-то, что позволит решить её легче»).
Так после краткого периода под лозунгом «всё, устал от этой гонки, не вижу ничего, пишу на с++» осмотрелся и для задач обсчета больших массивов данных изучил R и python.
И это очень понравилось — использовать удобный инструмент с его особенностями, заточенными под класс задач.
Да, можно написать и на с++, но трудозатраты не сравнимы, если нужно быстро что-то набросать.
Поэтому мне кажется, что для выхода из этого паралича нужно идти от задачи.
Если есть что-то, что позволит значительно облегчить разработку и получить качественный результат, то это стоит изучить.
Формула озвучена в известном мультфильме про крылья и ноги:
затраты_на_разработку_старым_инструментом > затраты_на_изучение_нового_инструмента + затраты_на_разработку_новым_инструментом
Под затратами_на_разработку_* надо, конечно, понимать суммарные на протяжении всего периода использования, а не только в новом отдельно взятом проекте.
В опровержение или, скорее, уточнение проскочившей вверху идеи, что надо только освоить основополагающиее принципы, а дальше будет легко писать на чём угодно, хотел бы сказать следующее.
Как мне кажется, переход на другой инструмент (если он не мотивирован просто оргштатными мероприятиями) позволит получить выгоду только в том случае, если будут использоваться его особенности.
Для примера — на питоне можно писать как на любом другом языке с использованием только операторов присваивания, математических, ветвления, циклов и т.д.
Но если не использовать comprehension, то не получишь ни ускорения в работе, ни ускорения в коде, ни кайфа от красиво решенной проблемы.
Так что переход на другой язык требует его изучения.
Невозможно пользоваться только core features и получать полную отдачу от освоенного языка/библиотеки/фреймворка/…
Надеюсь, написал по делу :)
А может быть и вообще стоит ориентироваться на поступающие задачи? Грубо говоря, понадобилось тебе писать под WEB — разберись, как писать под WEB с учетом современных технологий. Купил новый смартфон и не хватает функционала — возьми и разберись, как создавать приложения под этот смартфон. Ведь многие из языков и технологий разработки очень схожи и с каждым разом разбираться будет легче. Если что-то зацепит больше, чем просто текущая задача, ты всегда можешь копнуть глубже, возможно, даже переориентироваться на этот профиль. Если нет, то всегда можно оставаться на том профиле по которому ты работаешь изначально, но ты уже узнал что-то новое и при необходимости можешь это использовать вновь. В итоге, просто понимаешь, что практически любая принципиально новая задача — это вопрос скорее необходимости и времени. И без лишней философии пользуешься этим. А то, что кто-то пишет софт под квантовый аннигилятор — это, безусловно, здорово и круто, но тебе это в данный момент не нужно.
Соглашусь на своем опыте: просто в качестве инструментов решения конкретных поставленных задач, в свое время изучил python, java (для android), недавно ковырял ruby+RoR. Это все побочные для меня языки, но их изучение расширило кругозор. Да и после десятка+ ЯП разобраться еще с одним совсем не сложно (проблемой может быть разве что стандартная бибилиотека да повсеместно используемые, и от этого ставшие чуть ли не core, сторонние библиотеки).
Как правильно сказали выше, надо изучать подходы и методики разработки, паттерны и алгоритмы без привязки к конкретному фреймворку. И, самое важное, нужно быть в теме, но нельзя кидаться на каждый хипстерский баззворд. Например абсолютно бессмысленно переживать что нет возможности использовать Node.js если вы используете python/ruby/perl и т.д. Нода предложила асинхронную обработку информации. В любом современном языке это можно использовать и не менее удобно. И так далее.
Следовать моде — смешно. А не следовать — глупо. (с)
Удивляют комментарии, смысл которых заключается в том, что изучить новые языки совсем не сложно, это вопрос нескольких дней.
Возможно писать на уровне HelloWorld не сложно.
Но писать надежные, быстрые и безопасные приложения на каком либо языке, разве можно научиться за несколько дней?
Я к примеру изучал RoR по книжке. Да, что то я могу сделать на RoR. Но гарантировать, что мое приложение будет, например, безопасным, нет. Для этого мне нужно досконально знать как работает этот фреймворк, как передаются данные между компонентами, что внутри них происходит. А еще есть и вопросы оптимизации и деплоинга. И все эти вопросы врят ли повторяются с тем же Python, C++ или PHP. У каждого языка они свои.
Сколько времени нужно чтобы понять эти аспекты? Я считаю существенно больше, чем несколько дней. Как минимум полгода при условии, что есть подходящие задачи для языка, а не на уровне HelloWorld.
Поэтому я считаю, действительно есть проблема выбора инструментов программирования.
Возможно писать на уровне HelloWorld не сложно.
Но писать надежные, быстрые и безопасные приложения на каком либо языке, разве можно научиться за несколько дней?
Я к примеру изучал RoR по книжке. Да, что то я могу сделать на RoR. Но гарантировать, что мое приложение будет, например, безопасным, нет. Для этого мне нужно досконально знать как работает этот фреймворк, как передаются данные между компонентами, что внутри них происходит. А еще есть и вопросы оптимизации и деплоинга. И все эти вопросы врят ли повторяются с тем же Python, C++ или PHP. У каждого языка они свои.
Сколько времени нужно чтобы понять эти аспекты? Я считаю существенно больше, чем несколько дней. Как минимум полгода при условии, что есть подходящие задачи для языка, а не на уровне HelloWorld.
Поэтому я считаю, действительно есть проблема выбора инструментов программирования.
Знаю две причины изучать что-то:
1. Нужда
2. Интерес
С интересом понятно. На работе человек «творит» на… (подставьте что угодно, не пишу, чтобы не было кому угодно обидно), дома — на "..." (чем-то другом). Т.е. есть что писать дома — он и пишет, изучая по ходу что-то новое. Во если дома писать нечего, тогда пишется либо новая (очередная в мире) CMS-ка, либо еще какое-то решение «для всех», которому почти наверняка «не взлететь», ибо сил у автора почти наверняка на долго не хватит. Но — это путь интереса, когда человек делает что-то с радостью, и для себя.
Нужда — хуже и лучше одновременно. На работе поставили задачу поднять «слои» старого кода на "..." (впишите что-то сами). Хочешь или нет, а надо, либо ты будешь функционировать вместо этой программы. Хочешь — не хочешь, а приходится. Но качество изучения, конечно, будет хромать — как вопрос закроется, так и язык забудется. Если только не перерастет в интерес (см. выше) :)
Да, есть вариант: понравился кому-то язык "..." (варианты — фреймворк "...", и т.д.), он бросил опостылившую работу, и нашел себе место, где эта технология используется и лежит в основе. Пожалуй, лучший путь, как ни крути! ))
1. Нужда
2. Интерес
С интересом понятно. На работе человек «творит» на… (подставьте что угодно, не пишу, чтобы не было кому угодно обидно), дома — на "..." (чем-то другом). Т.е. есть что писать дома — он и пишет, изучая по ходу что-то новое. Во если дома писать нечего, тогда пишется либо новая (очередная в мире) CMS-ка, либо еще какое-то решение «для всех», которому почти наверняка «не взлететь», ибо сил у автора почти наверняка на долго не хватит. Но — это путь интереса, когда человек делает что-то с радостью, и для себя.
Нужда — хуже и лучше одновременно. На работе поставили задачу поднять «слои» старого кода на "..." (впишите что-то сами). Хочешь или нет, а надо, либо ты будешь функционировать вместо этой программы. Хочешь — не хочешь, а приходится. Но качество изучения, конечно, будет хромать — как вопрос закроется, так и язык забудется. Если только не перерастет в интерес (см. выше) :)
Да, есть вариант: понравился кому-то язык "..." (варианты — фреймворк "...", и т.д.), он бросил опостылившую работу, и нашел себе место, где эта технология используется и лежит в основе. Пожалуй, лучший путь, как ни крути! ))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вы тоже можете стать жертвой паралича разработчика