Что стоит прокачивать накануне эры постпрограммирования?

 Публичный пост

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

Освоение новых ЯП - дело небыстрое, плюс как правило они эволюционируют, развиваются. То есть обычно стоит задача "догнать и перегнать". И вот трата времени на "догнать" (не говоря уже о "перегнать") выглядит не особо эффективной, причём наверное не мне одному.

К тому же повальная мода на нейросети даёт ощутимую надежду на скорое появление постпрограммирования. Как когда-то высокоуровневые ЯП "отодвинули" человека от ассемблера и железа, а позже фреймворки усугубили разрыв, нейросети имеют возможность "нарастить" на это всё добро ещё один слой абстракций и интерпретаций. И всё во имя снижения порога вхождения и увеличения эффективности и универсальности утилизации рабочего времени.

Так вот. Отбрасывая шутеечки и ответы в стиле "Учить Java никогда не поздно и выгодно", "А кто сказал, что на ассемблере уже не пишут?" и "Земля большая, программеры с устаревшими навыками всегда найдут себе применение" - что стоит прокачивать на пороге подобного постпрограммирования, как думаете?

35 комментариев 👇

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

Помимо этого как долгосрочный тренд это Soft Skills и желание разбираться не только в технических аспектах проекта, но и в бизнесе. Аля продуктовый программист с некоторыми знаниями продуктового менеджмента.

  Развернуть 1 комментарий
  1. Почему когда все говорят "алгоритмы" тут же вспоминают про "методы сортировки" или какие-нибудь красно-черные деревья. Это как раз не самая полезная часть "алгоритмов"

  2. Если уж быть совсем честным, я не очень представляю как программиста подпустят к "бизнесу". Я не очень понимаю, что значит "разбираться в бизнесе". Бизнес – это про маркетинг, продажи и отношение с клиентами в первую очередь, там нет места для технических решений, да и сам "продукт" весьма косвенно относится к бизнесу. Никогда не видел, что програмисты вообще были в курсе про какие-то продажи и маркетинг или это им помогало как-то в работе.

  Развернуть 1 комментарий

Бизнес - это не только маркетинг и менеджмент, но и доменные знания, например, или знание бизнес-процессов. Гораздо удобнее, когда знаешь, о чем программируешь.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N
"Бизнес" - это про то, когда в работе отталкиваешься от того, какие твои действия приносят наибольший value компании

  Развернуть 1 комментарий

Поддерживаю! Фундаментально мало что меняется.

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

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

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

Невозможность разгонять бесконечно мегагерцы подтолкнула к развитию параллельного и асинхронного программирования. Всё большая диджитализация бизнеса (привет Короне) гонит всех в облака и стимулирует поиск новых подходов к разработке (микросервисы) и способов справляться с большими нагрузками. Плюс развитие итернета и сбор биг даты сделали машинное обучение снова актуальным (нейронные сети сколько уже существуют? лет 70?).

  Развернуть 1 комментарий

@XwB6h3e7SVlgpvJC ты про такие штуки как 9000-е ISO, например?

  Развернуть 1 комментарий

Я имела в виду более прикладные вещи, т. е., как построены процессы в тех отдельно взятых компаниях, в которых ты работал, потому что они завязаны на реальную индустрию и реальные задачи.

Про общие стандарты я даже не подумала :-) Кстати, хороший пункт.

Может, даже не прямо ISO-стандарты, а все вот эти "You-Name-It-Body-of-Knowledge"-талмуды.

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

Знание ISO, как мне кажется, полезны только либо если стандарты уже внедрены в компании, либо если сам собираешься их внедрять.

  Развернуть 1 комментарий

когда я проходил курсы повышения квалификации и нас пичкали 9000-ми ISO, меня удивило, насколько это общеприменимая штука. Её влёгкую можно адаптировать даже к построению адекватной семьи =D

  Развернуть 1 комментарий

Да, есть такое :-)

Правда, у меня только ITIL-сертификация, но мне очень нравилось, что там очень рационально все.

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

Так что я сертифицировалась, испытала вельтшмерц и продолжила работать вопреки стандартам :-)

  Развернуть 1 комментарий

Same shit, коллега =D Меня тоже по сути отправляли, чтобы я научился все эти требования выполнять номинально и нейтрализовывать аудиторов... И это очень, очень огорчительно.

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...
Valeriy Shunkov Разработчик микросхем для космолетов 26 августа 2020

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

И, в более широком смысле, доступные в железе мощности общего назначения уже скоро упрутся в потолок, и будет полезным понимание сферы низкоуровневой оптимизации кода под железо, процессорных архитектур, компиляторов и всего такого.
Это полная противоположность "backend as a service" и "программированию без написания кода", но есть мнение, что ещё один слой упрощения работы кодеров за счёт увеличения требований к железу железо просто не вытянет.

  Развернуть 1 комментарий
Аватар Programistich Programistich 27 августа 2020 Команда Клуба

Так а как работают куски кремния?

  Развернуть 1 комментарий

@Programistich, начать изучение этого вопроса разумнее всего с книги "Цифровая схемотехника и архитектура компьютера" за авторством Харриса и Харрис.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

Думаешь, надо? Я что-то посмотрел на книжный клуб, и мне показалось, что он немного про другое. Харрис и Харрис - это все полноценный учебник, а не научпоп за авторством какого-нибудь Сапольски.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

Я думаю, никакого "пост-программирования" не будет. Да, будут появляться новые языки и парадигмы, новые инструменты и методики; но для кардинальных изменений нет никаких предпосылок.

Более того, я давно уже заметил такую штуку: каждый прорыв откатывает нас в каком-то смысле назад. Только мы вздохнули, что наконец у всех мощные десктопы и большие мониторы - хуяк, здравствуй, мобильная революция. Только привыкли работать с мощными инструментами - хуяк, привет, k8s и голанг, мы снова пишем мейкфайлы, C-подобный говнокод и баш-скрипты, снова срем логами в stdout. Мы вырвались из XML-ада Java только для того, чтобы очутиться в YAML-аду helm.

Это вечная спираль.

  Развернуть 1 комментарий
Roman Pavlov System Development Engineer 26 августа 2020

Политэкономия всему голова.
Инструменты вторичны, запрос общества - наше всё.

  Развернуть 1 комментарий

и что на эту тему посоветуешь? Конкретные книги, статьи, выступления?

  Развернуть 1 комментарий

Я начал с серии Рождение Революции, и История Религии, а сейчас изучаю Капитал.

Жукова интересно слушать только когда он рассказывает не свои мысли, а на основе источников компилирует материал. Как только разговор заходит про текущий момент и теорию управления — там прям туши свет, советский бдсм куколдизм торчит из всех щелей.

чО дальше — пока не знаю, надо бы посмотреть на иностранные академические источники.

  Развернуть 1 комментарий

@romangoward Не хочу давать не прошенный совет, но недавно смотрел интервью с Сергеем Гуриевым где в частности обсуждались актуальные книги по экономике. Так вот. В нём он говорит, что Капитал Маркса уже не актуален в наше время и из него мало что можно подчерпнуть полезного и посоветовал некоторые книги, которые отражают ситуацию в экономике наших дней. Вот ссылка, вдруг будет интеренсно ;)

  Развернуть 1 комментарий

Маркс не может быть не актуален, поскольку за 150 лет его ни разу не поймали на лжи или перевирании фактов (многие пытались, да).
Капитал — большая работа, основной ценностью которой является чёткое определение взаимоотношений внутри общества в контексте исторических изменений материального базиса :)

А книжки, которые Гуриев посоветовал в ролике, я себе добавил в список.

  Развернуть 1 комментарий

К тому же повальная мода на нейросети даёт ощутимую надежду на скорое появление постпрограммирования

Я буду не столь оптимистичен и неросети немного перехайплены. Но и настоящее "программирование" умирает в среде энтепрайзов и прикладной разработки. Все эти круды, формочки, ворочанье jsonов, бизнес-аппы, финтех старатпы и прочая работа для IT-сантехников – это просто чудовищно. Надеюсь скоро все это минимизируется испльзованием backend-as-service решений, nocode, генераторами интерфейсов и прочими вещами, а для бизнес-логики хватит и AWS Lambda." С этим всем справятся продуктовые менеджеры, аналитки etc, без привлечения кодерков. "Настоящее программирование" останется как узкоспециализированная работа: мб системное программирование, embedded, какой-нибуь геймдев etc...

Освоение новых ЯП - дело небыстрое.

Только если это плюсы или ,например, какая-нибудь скала с cats, то да, тогда долго.

что стоит прокачивать на пороге подобного постпрограммирования, как думаете?

Я вот иногда мечтаю, что через лет этак 5-10 большая часть из нас может оказаться безработными и рынок прикладной разработки схлопнется. В лучшем случае можно попробвоать переквалифицироваться во что-нибудь смежное не связанное с разработкой. Главное не унывать и помнить, что жизнь прекрасна сама по себе, не важно кем ты работаешь, а важно с кем, и чтоб на жизнь хватало.

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

  Развернуть 1 комментарий

Только если это плюсы или ,например, какая-нибудь скала с cats, то да, тогда долго.

Я перекатилась с ABAP на плюсы за полгода)

Плюсы это ж не пролог какой-нибудь. Обычный императивный язык. Если уже умеешь программировать на любом императивном ОО языке, достаточно одну книжку внимательно почитать, чтобы тебя на работу взяли. А дальше дело практики.

  Развернуть 1 комментарий

Не, плюсы это ужас. Даже после Java. Даже если на плюсах писал ещё в студенческие годы, когда на Java ещё не писал потому что Java была версии 1.1.

На плюсах нужно писать только если заставляют :-)
Снизу есть C, он лучше подходит для системных вещей.
Сверху любой нормальный язык программирования.
Сбоку C++ начинает вытесняться Rust'oм, аки Java Котлиным, и это хорошо. Но туева куча legacy на плюсах будет жить ещё лет 20 минимум...

  Развернуть 1 комментарий

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

И не знаю что за претензии вообще, прекрасный язык)

  Развернуть 1 комментарий

@megakott, Давайте не скатываться в обсуждение плюсов, легаси или чего-то ещё, кого это волнует. Это не важно, заказывают музыку всё равно не технические люди. Будут плюсы жить ещё 100 лет, а раст врядли, у раста нет ни спонсоров нормальных, ни маркетинга, ни солидной грамотной пропаганды с промыванием неокрепших кодерских мозгов, чтоб из каждого утюга. "Zero cost abstractions, ownership model" - крайне слабые лозунги для широких масс. Крупной и стабильной корпорации за спиной теперь уже тоже нет. Даже стандарта и формальной спецификации и то нет.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

@sbogolepov. Я надеюсь, вы не серьезно.
Подобные примеры с программированием на плюсах имеют мало общего. Такой же ролик можно сделать и про любой другой язык. Впрочем, он будет даже смешнее с некоторыми высокоуровневыми языками (js, c#).

  Развернуть 1 комментарий

Удалил комментарий, так как у меня на телефоне не отображалась ссылочка. Оказывается, всё было норм. Вот, о чём речь:


https://twitter.com/gf_256/status/1285217798642454531

Отчасти серьезно.
Конечно, можно сделать WAT-ролик про любой язык, но плюсы с лёгкостью обгонят по количеству таковых любой другой :)
Иначе с языком, подход к развитию которого основан на методе "лебедь, рак, щука и отсутствие агрессивного deprecation cycle", быть не может. И, увы, аналога TypeScript/Kotlin для плюсов человечеству не видать.
То есть да, плюсы переживут всех и вся, но это не из-за того, что он такой замечательный.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N переключаться между языками, что архитектурно и функционально похожи друг на друга - конечно, не самая большая проблема. Но, например, с появлением квантовых компьютеров и программирования под них могут появиться совершенно иных подходов. И нынешние Java и Go покажутся в сравнении с ними новому поколению программистов тем же, чем кажутся COBOL и Prolog для нас.

Да что там квантовые компы... Мне с Java и PHP сложновато далось изучение SAS Base/Macro. Банально потому, что там идеология и архитектура другая.

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

@Doredel, я могу ошибаться, конечно, но ваш случай очень смахивает на эффект Даннинга-Крюгера. Вот человек 17 лет на крестах пишет и так и не выучил их, более того - так и не смог встретить того, кому это удалось: https://m.habr.com/ru/post/497114/

Мы все благодарны C++ за то, что он был и за то, что новые языки не повторяют его ошибки дизайна; но всерьез говорить в 2020 про то, что кресты - классный язык?..

  Развернуть 1 комментарий

@EduardSurov а кто-то разве говорил, что я досконально знаю язык и могу ответить на любой вопрос?

Вообще, сомневаюсь что кто-то сможет ответить на все вопросы по любому языку. У C++ особая репутация, которую создают в основном все те же плюсовики, придумывающие эзотерические задачки.

С++ - классный язык, потому что он гибкий. В отличие от многих других. Он нарушает дзен питона, но он и не питон, поэтому его и любят.

There should be one (and preferably only one) obvious way to do it.

Теперь о той статье, которую вы скинули. Я, конечно, читала ее по-диагонали. Но я обратила внимание на основную аргумантацию автора. Она примерно такая: если пытаться сделать что-то особенное, легко выстрелить себе в ногу, а если не пытаться, то зачем плюсы?

А плюсы не для таких задач, в которых без них можно справиться. Просто плюсы не создают нескольких важных слоев абстракции и требуют навыков ручного управления памятью. Зато вам не нужно учить как работает сборщик мусора в вашем языке или думать во что развернется такой удобный foreach в IL. What you see is what you get. Но не обязательно, "What you thought you see is what you get".

И еще. Когда я искала работу, я разместила два резюме. В одном был шарп. В другом плюсы. Угадайте, какие предложения были на шарп и какие на плюсы.

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

  Развернуть 1 комментарий

@EduardSurov, у меня есть еще более провокационный ответ.

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

Русский язык недостаточно классный?

  Развернуть 1 комментарий

@Doredel, спасибо, все понятно.

  Развернуть 1 комментарий

Попробую ответить с двух позиций.

I. Узкое понимание вопроса - про языки программирования

Рекомендую изучать языки, предлагающие новые концепции и идущие в сторону строгости. В этом смысле языки с динамической типизацией - тупик. Для тяп-ляп-уяк-впродакшн или прототипирования сойдёт, для построения сложных систем с 500к строк - уже нет. Слабое звено - всегда программист с кривыми руками. Чем больше работы и проверок перекладывается на компилятор, тем лучше всем - и бизнесу, и программерам. Пример старых языков с подобным подходом - сдохший Паскаль с очень строгим компилятором. Примеры новых строгих ЯП с новыми концепциями - Haskell и Rust. Первый - жемчужина функционального программирования, там обкатываются все новые идеи. Второй - низкоуровневое программирование, сопряженное с безопасной работой с памятью.

II. Широкое понимание вопроса - про программирование вообще
Освойте смежную профессиональную прикладную область, чтобы программирование было в этой области инструментом решения задач. В постмодерновом мире чистые программисты (кодеры) не нужны, их пучок за $100, гляньте на Индию и Юго-Восточную Азию. Люди за крохи готовы "войти в IT" и программировать. Конкуренция высокая, а качество никого не интересует, главное быстрее тяп-ляп-уяк-уяк.
Становитесь не просто программистом, а человеком, решаюшим проблемы.

  Развернуть 1 комментарий
V.exeR Аналитик-разработчик автор 27 августа 2020

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб