Безликий код убьет программирование, и ничего мы с этим не сделаем


    Во время очередного спора знакомый озвучил мысль, которая меня очень сильно задела. «В большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом. Поэтому их код легко читаем, предсказуем и надежен. И поэтому крупный бизнес выбирает Go». Это достаточно мощный аргумент, над которым нужно как следует поразмыслить, прежде чем опровергать.


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


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


    Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом. Так компании будет намного комфортнее. Бизнес не хочет зависеть от случайностей. Мысль, что плохое настроение ведущего разраба отнимет у бизнеса кусочек прибыли, не нравится топ-менеджерам. Они стали топ-менеджерами, потому что хорошо умеют избегать ситуаций, когда их священный бизнес теряет деньги. А мы сейчас живем в то время, когда «хорошо сделанное» и «прибыльное» — разные вещи.


    И я прекрасно понимаю, как мы к этому пришли. Сейчас объясню, следите за пальцами:



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


    Что я вообще нахрен делаю?


    Вот я продумываю архитектуру высоконагруженной системы, но в 95% случаев ее будут применять, чтобы быстрее отсортировать на телефоне селфики с узорами и фоточки любимой собаки. Вот я разрабатываю VPN-клиент, и что с ним будут делать? Смотреть всякую порнуху и тупые пиратские фильмы?


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


    В ИТ делают хорошие вещи, но их процент ничтожно мал. Большинство обслуживает дурацкие потребности, которых раньше просто не существовало, потому что не существовало ИТ. То есть, инженеры не делают великие вещи, инженеры просто поддерживают инфраструктуру перекачки бабла между людьми.


    В таких условиях писать хороший код перестает быть необходимым. Это нужно только для того, чтобы мне было веселее работать, и я подольше не выгорал. Но рано или поздно приходит топ-менеджер и говорит: «Все, заколотите гвоздями и пуляйте. Пора стричь бабло».


    Вместо абстрактного «всеобщего блага» ИТ научилось потакать низменным хотелкам и только за счет этого выросло в гигантскую индустрию, где работают сотни миллионов людей. Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.


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


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


    А я думаю — мне это всё нахрен не нужно. Это все вызывает отторжение.


    Если хорошо присмотреться, мой VSCode набит опасными симптомами. Мой tslint не разрешает добавить мне лишний пробел. Мой код не билдится, если я назвал переменную не с той буквы. Мой компилятор не будет работать, потому что я не добавил комментарии к публичному методу. Тут все просто — пишите, ребята, одинаковый код. Безликий код. Это вам не роман, какой к чёрту авторский стиль?!


    Я в целом согласен, что подобные конвенции — хорошая штука, но только до тех пор, пока они касаются внешнего вида кода. Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар. Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже». Звучит абсурдно? Вот так и будет. Серьёзно. Да так уже есть. Они не добавили дженерики в Go, потому что дженерики — сложные.


    Go — это бизнес-эффект, а не инженерное решение. Он сам себе противоречит. Вот он хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности. Дженерики существуют именно ради надёжности, чтобы предвосхищать потенциальные баги dev-time. И да, они довольно сложны.


    Программируя, я хочу заниматься творчеством. Хочу иметь огромное число опций, когда дизайню систему. Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение. Но это же обман! Пусть он и сработает, но всегда есть решение лучше. А под давлением того, что у нас нет бюджетов на качественные решения, мы сами убиваем софт, и потом разочаровываемся, что все плохо работает.



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


    Я всегда верил, что базовый посыл разработки звучит так: «Все, что может быть автоматизировано, должно быть автоматизировано». Но вот ирония — мой посыл тоже фатален.


    Я не готов делать что-то, что могла бы делать машина, которую я могу построить. Это нерационально, а меня учили быть рациональным. Но раз я должен все автоматизировать, выходит должен автоматизировать и автоматизацию — то есть разработку. И получается должен быть рад языкам, которые постепенно нас к этому подводят. То есть моя профессия, как и большинство других, в идеальном мире существовать не должна.


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


    Мое решение проблемы — утопическое, и не выдержит никакой критики. Я понимаю, что его уже поздно предлагать, но все же.


    Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.


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

    Support the author
    Share post

    Similar posts

    Comments 358

      +29
      Программируя, я хочу заниматься творчеством.

      Сорян, Бро. Все хотят (ну или когда-то хотели :)), согласен. Но это плохой путь. Разработчики в первую очередь нужны для того, чтобы делать какой-то продукт, который приносит деньги. И чем проще среда, тем продуктивнее будет разработчик (но, как говорил Великий, «Всё следует упрощать до тех пор, пока это возможно, но не более того.»). Чем больше кода можно написать достаточно эффективно и при этом стандартно — тем лучше. Поэтому решения типа Go и появляются — они отвечают современным требованиям серверной («микросервисной») разработки и облегчают написание таких программ. Никого не интересует творчество. Вернее интересует, но это лишь малая часть продукта. В основном нужно просто «прокопать от забора до обеда», и чем меньше усилий для этого нужно затратить, тем лучше, ИМХО.
        +5
        Кстати есть и обратная тенденция. 1с. Исходная идея что все должно быть как можно проще и ближе к предметной области выросла в монстра с кучей разных фич, особенностей и т.п. И продолжает идти в сторону усложнения (пусть и на прикладном уровне, машинное обучение у них в планах, ин мемори субд добавили).
          +8

          Вообще не совсем понятно, по каким критериям судят о красоте кода: почему красивый код — это обязательно долго и дорого? Может быть подход, при котором получается долго и дорого, не так уж и красив на самом деле.

            +2

            Забавно, но не то, чтобы сами компании до конца понимали, для чего нужны разработчики.


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


            Также и с самой разработкой, с критериями оценки производительности.
            Лично у меня недавно была ситуация: позвали в проект, существовавший без архитектора, поставили задачу оптимизации. После недельного аудита: готового набора текстов по архитектурным проблемам, гайдов по критическим проблемам команды( а у команды были весьма серьезные проблемы ), заявился владелец бизнеса и усевшись рядом с техдиром поинтересовался. — "а какой вы написали код? вы что, не работали все это время?!".


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

              +9
              Я тоже раньше так думал. Я раньше думал, что творчество заключается в том, что я располагаю символы в нужном порядке, делаю хорошую архитектуру, умные маленькие и быстрые функции, красиво называю переменные (не одной буквой, но и не предложением). В общем, думал, что творчество — это то, о чем говорил автор статьи. Но когда я начинаю рассказывать об этом другим программистам, некоторые из них говорят: «да ну, ты что, правда об этом обо всем думаешь, когда пишешь код?». Я отвечаю, углубляясь в философию и пытаясь привлечь для объяснения аналогии: «Программирование — это управление сложностью. Разрабатывать программу нужно так же, как получать зерна из граната: иногда вместо того, чтобы сосредоточиться на извлечении зерен, нужно сосредоточиться на том, чтобы убрать все лишнее. Так можно не только чистить гранат, но и жить: убрать все лишнее и остаются только ценные зерна, так же можно и программировать — убирать лишний код, чтобы остался только тот, который действительно важен». Но и эти мои мысли не находят поддержки среди программистов. Я пришел в выводу, что все это — психологическое шасси, которое нужно лишь некоторым людям, чтобы обосновать свою деятельность, иметь идейную и философскую поддержку, особенно это важно в моменты, когда ты остаешься один на один с бездной неизвестной сложности, загнанный в угол ограничениями, и связанный обязанностью решить все эти проблемы. И это для меня теперь является творчеством — это когда есть обстоятельства, которые обычно против тебя, а ты пытаешься найти оптимальный выход, адекватный сложившейся ситуации. А пишешь ли ты при этом буквы или нет, хороша ли твоя архитектура… Все это или что-то из этого может иметь ценность или нет в зависимости от обстоятельств, которые в разных проектах и задачах никогда не совпадают.
              • UFO just landed and posted this here
                  0
                  Так я и говорю, что философия в бизнес-разработке неприменима. В отрыве от контекста личности не бывает универсальных принципов, а внутри бизнеса — другие механизмы, подчиняющиеся другим законам логики. Поэтому я перестал беспокоиться об авторском стиле. Я перестал навязывать команде кодестайл, следование стандартам и так далее. Даже архитектура — вещь приходящая и уходящая. Ты просто должен решить, важна в этом месте архитектура или нет. Если это локальная хрень, которую завтра выпилишь или за полчаса перепишешь, или вообще, возьмешь стороннее решение — пусть она лучше будет уродлива, чем тратить на нее время и ресурсы, лучше применить мысль там, где это действительно нужно. Все это не влияет на конечный результат от слова «полностью». А принцип всего лишь один — фигачишь код -> анализируешь результат -> в следующий раз делаешь меньше работы, делая подобную же задачу. Даже не знаю, опять получается, что я постулирую принципы. Но невозможно прочитать их и понять на том уровне, чтобы использовать, надо чтобы они родились в голове каждого конкретного программиста, и у каждого они будут свои.
                0
                Все очень просто: мы переносим сложность из кода в его поддержку и оркестровку: микросервисы->docker->kuber-->?.. Сложность останется. И хорошие программисты станут хорошими devops, оставив писанину скучного кода новичкам.
                  –1
                  Рано или поздно программист понимает, он не творец, а подмастерье
                    0
                    Ничего не мешает ему быть творцом, просто творчество — это не когда ты делаешь что-то гениальное, математически точное, архитектурно красивое и идеальное. Творчество — это когда ты делаешь это так, чтобы другие люди видели в этом все вышесказанное. При этом для тебя это может быть просто квадрат черного цвета.
                    –1
                    А затем приходит нужда написать что-то сложное типа универсального искусственного интеллекта, который в принципе нереально написать просто и маленькими модулями… И все эти линейные программисты оказываются способными только проедать бюджет инвесторов и создавать ужасные решения на миллионе кастылей, которые не способны к масштабированию и умирают в корчах. А единичные проекты типа kiberis.ru так и остаются уникальными, потому что повторить их слишком дорого и вероятность успеха очень мала. Именно из-за того, что программисты привыкли к простым задачам.

                    Поэтому ничего с кодом не произойдет. В течение десятка лет появится автоматизация большинства задач линейных программистов, и перед ними станет выбор — либо переходить на новый уровень программирования и создавать сложный код с продуманной архитектурой (что получится мало у кого), либо идти в другие профессии. Потому что просто написание безликого кода станет ненужным.
                      +3
                      А единичные проекты типа kiberis.ru

                      гомеопатические препараты

                      успех

                      Нет.
                    +11
                    Надо создать профессиональную ассоциацию программеров
                    неговнокодеров
                    С уставом и всё-такое
                    В других специальностях есть подобные институты
                    Будет, с одной стороны, такой знак качества, а с другой — хранители истинного духа и традиций
                    Как дети-индиго, только наоборот
                      0
                      Не совсем конечно ассоциация, но есть подобное течение: en.wikipedia.org/wiki/Software_craftsmanship
                        +13
                        Создать можно, но не поможет. Замените в тексте статьи программиста на кузнеца, и всё будет так же. Он тут такой, красивый и в белом пальто — делает мир лучше, искусством занимается и тэ дэ, а ему тут нннннннннааа по голове непонятными штуками под названием «стандартизация» и «индустриализация». И как жить, когда кто-то станками клепает взаимозаменяемые детали тысячами, пока ты со всем своим искусством и трогательным отношением делаешь одну?

                        С кодом всё точно так же. И ниши для штучного программирования и искусства всё равно всегда будут, только вот все в них не влезут.
                          +2
                          только вот все в них не влезут.

                          С влезанием нет проблем.
                          Но в таких областях как правило меньше платят. Ровно настолько, чтобы количество желающих было лишь чуть-чуть больше спроса.
                          +2
                          Вы правы. И как пример можно привести адвокатское и врачебное сообщества в США. Чужих они не пускают. Совершенно неэкономическими методами.
                            +1

                            Чужих — это тех, кто не отучился в соответствующих учебных заведениях?

                              +2
                              И что в этом хорошего?
                                –1
                                Медицина в США — лучшая на планете. Как и юристы.
                                  +1
                                  Нет, по крайней мере, медицина там далеко, скажем так, не самая оптимальная. И во многом за счёт непускания чужих.
                                    +2
                                    Медицина в США — лучшая на планете


                                    «Я тебе конечно верю, разве могут быть сомненья».

                                    В контексте «лучшей медицины» я еще слышал про Израиль, Испанию, Британию и Канаду. Почему верить я должен именно вам?

                                    А еще даже если вы выработаете критерий «лучшести» медицины и докажете, что она лучшая именно в США, вам также предстоит доказать, что закрытость — это именно причина топового места и медицина лучшая именно благодаря этому, а не вопреки.

                                    Как и юристы.

                                    Собственно все то же самое, просто замените медицину на юриспруденцию.
                                –3

                                Некто Robert C. Martin похожему посвятил минимум одну книгу. Получилось максимально уныло, с кучей нравоучений. К сожалению, ее иногда спрашивают ашары.

                                  +6
                                  Надо создать профессиональную ассоциацию программеров
                                  Как дети-индиго, только наоборот
                                  сепия-старцы?)
                                  +2
                                  У Go остается свобода в выборе паттернов, алгоритмов и имен переменных. Но многие задачи имеют простое и правильное решение. Это удобно и делает код чище и легче читаемым. Можно зайти в произвольное место стандартной библиотеки, посмотреть как и что написано, без труда понять это и использовать похожий подход. Ничего в этом плохого нет.
                                  Если сравнить с stl от c++ это просто небо и земля. Там хоть и исходники доступны, но понять что же все-таки происходит. Надо как-то понять в каком месте какого шаблонного класса объявлен какой тип и в каком шаблоне он используется и зачем. Вместо объявления интерфейса и требования соблюдения этого интерфейса есть привязка к именам типов и методов и это так усложняет понимание кода, что надо гораздо больше времени чтоб вникнуть. Не говоря уже о том чтобы скопировать увиденный подход к себе в приложение. И вот в чем проблема когда задачу можно решить 15ю способами одна и та же проблема в разных местах приложения будет решена по-разному. Часть из этих решений будет простыми и неправильными. А это уже ведет к разному поведению и такие куски кода может быть тяжело заметить, чтобы свести к общим функциям.
                                    +3
                                    Очень знакомо и при знакомстве с языком меня сильно удивило. Как-то привык я, что лезть в библиотеки это дело гиблое. Там всегда черт ногу сломит. Проще погуглить решение проблемы, авось кто-то сталкивался. А в Go лезть в код рантайма стало обычным делом, когда мне что-то непонятно или любопытно. Я бы и мог тоже самое сделать с помощью тестового проекта, дебаггера, гугла, стэка, но незачем. Быстрее прочитать и самому все увидеть.
                                      +4
                                      Когда я программировал на C, приходилось заглядывать в код ядра, что бы разобраться в пользовательском приложении.
                                      С тех пор я перешел сначала на Haskell, потом на Scala, и что бы разобраться в библиотеке часто достаточно посмотреть ее интерфейс, даже не документацию. Я этим очень доволен.
                                        0
                                        Ядра чего — языка или ОС?

                                        Впрочем, в обоих случаях непонятно, для чего это может потребоваться, и каким образом это может зависеть от языка.
                                          0
                                          Ядра ОС (FreeBSD, Linux).
                                          Система типов не достаточно выразительная, что бы полноценно описать интерфейс.
                                            –1
                                            Если для понимания особенностей работы приложения приходится лезть в код ядра ОС — это значит, что есть непонимание механизма работы функций системного API или сомнения в правильности их работы. Каким образом это может зависеть от языка, на котором написано приложение?
                                      +2

                                      Не далее как вчера мне потребовалось ровно 10 минут, чтобы понять, почему std::any_cast некорректно работает в libstdc++.

                                        +2
                                        C++ и stl создавались в прошлом веке с целью заткнуть текущие дыры в разработке. Не удивительно, что получилось не слишком изящно.
                                        Сравнивать надо не с ними, а с академическими Haskell и SML, и с современным, вобравшим лучшие практики Rust.
                                          –3
                                          Ну это вы загнули. Мы в работе используем С++17, который достаточно свеж. :) Сама концепция определения требований у шаблонов хромает. Когда привязка идет не к интерфейсу, а по наличию методов или под-классов с нужными методами. Их нет — получишь ошибку с ссылкой на дебри шаблонной функции где сигнатура не совпала или метод попробовали вызвать. Было бы следование интерфейсам как в Go — сразу получили бы ошибку, мол класс не реализует интерфейс A, надо добавить метод B.
                                            0
                                            Дизайн унаследован с древних времен, его уже тяжело переделать. Во многом от сюда и сложность поддержки библиотек.
                                              0
                                              К С++ шаблоны были прикручены сбоку, отсюда и все проблемы. Возьмите язык, где шаблоны были изначально и удивитесь как всё внезапно становится понятно: run.dlang.io/is/vjmZFx
                                                0
                                                Ладно бы только сбоку — они ж прикручены так криво, что кривее и не придумаешь.
                                          +25
                                          я программирую после работы.
                                            +1

                                            Что программируете? Почему не можете это сделать работой?

                                              –1

                                              Главное, чтобы не вместо.

                                                0
                                                а что мешает делать и то и то?
                                                  0
                                                  Меня всегда искренне удивляли такие вопросы.
                                                  Во-первых, далеко не за всё, что интересно пилить какому-то человеку, другие люди готовы платить хорошие деньги, или вообще готовы платить. Все-таки группы проектов «интересно» и «выгодно» часто не пересекаются.
                                                  Во-вторых, я для себя давно уже вывел простое правило: нельзя смешивать хобби и работу. Нельзя. Ни в коем случае, ни при каких обстоятельствах.
                                                  Я вот, например, очень люблю программировать, и очень люблю ходить по горам.
                                                  Но есть одно «но». Когда я себя неважно чувствую, или когда на улице идет ливень стеной и семибальный шторм, я наврядли захочу пойти в поход, как бы я сильно не любил это дело. А если бы и пошел, то наврядли получил бы от этого удовольствие, а мог бы еще проблем со здоровьем потом огрести. Поэтому лучше посижу в тепле и поколдую над программами в своё удовольствие.
                                                  Точно так же, я очень люблю разрабатывать ПО. Решать сложные задачи, добиваться результата, делать код и архитектуру лучше. Но в один прекрасный день у меня может оказаться такое настроение, что мне не захочется программировать, а захочется пойти в поход — птички поют, солнышко светит, друзья зовут за приключениями, никакого желания сидеть в офисе или дома, смотреть в монитор и созваниваться с заказчиками, а о коде голова вообще не думает и не хочет соображать, Но… нет. Есть заказчики, есть таски, есть дедлайны, есть проблемы, требующие срочного решения — в итоге я вынужден насиловать себя в этот день работой (хотя в другой день я бы занялся этим с радостью, и даже задержался бы до глубокой ночи, ковыряя какую-нибудь интересную задачу). В итоге постепенно совершенно остываешь к любимому делу и оно начинает тебя напрягать, как раз-таки из-за его ежедневной «обязательности» из-за того что оно стало работой.
                                                    0
                                                    То есть вместо того, чтобы заниматься любимым делом, пусть иногда и с усилием, вы предпочитаете всегда заниматься нелюбимым делом с усилием? Я вас правильно понял? Или вы вообще не работаете?
                                                      +1
                                                      Я все больше и больше прихожу к идее, что лучше заниматься в рабочее время и в обязательном порядке пусть и не слишком любимым делом (главное, чтобы к нему не было отвращения, и чтобы за него хорошо платили), чтобы не терять искреннее удовольствие от занятий по-настоящему любимыми делами добровольно в свободное время.
                                                      • UFO just landed and posted this here
                                                          +2
                                                          Вы подменяете желаемое действительным. Можно и нужно смешивать хобби и работу, нужно получать удовольствие от работы, особенно когда работа — большая часть жизни.
                                                            0
                                                            Можно и нужно смешивать хобби и работу
                                                            особенно когда работа — большая часть жизни

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

                                                              0

                                                              Для начала нужно разобраться, что такое работа. И что такое хобби. И причем тут связь с удовольствием.

                                                                0
                                                                Для начала нужно разобраться, что такое работа. И что такое хобби.

                                                                Работа — основной источник дохода. Хобби — деятельность, которой человеку нравится заниматься во время, свободное от работы.


                                                                И причем тут связь с удовольствием.

                                                                Это тема обсуждения в данной ветке, очевидно.

                                                                  0

                                                                  Тогда все становится еще более запутанным. Получается, что вы не хотите, чтобы интересное занятие приносило доход. И не хотите, чтобы нравилось то, чем вы занимаетесь на работе.


                                                                  Мне не понятна эта связь, учитывая, что эти концепции искусственны сами по себе. Нет в биологическом мире разницы между "работой" и "хобби". Вам не кажется, что вы просто занимаетесь чем-то не тем?

                                                                    0
                                                                    Скорее хочется, чтобы была такая область, при занятиях которой не приходилось думать о нерелевантных факторах (вроде заработка денег, принесения пользы бизнесу и тому подобных).
                                                                      0

                                                                      Это вполне возможно. Надо поискать просто

                                                +37
                                                Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаково плохо

                                                Fixed.
                                                  +9
                                                  Я, как и большинство инженеров, верю, что творю великие вещи.

                                                  Такие штуки как docker, kubernetes не достаточно великие вещи? Восхищаются готовым продуктом(nginx, postgresql, mysql и т.д.), а не его исходным кодом.

                                                    –2
                                                    Похоже у автора просто приступ аллергии к Go.
                                                      +6
                                                      А вы в курсе, что пришлось сделать команде kubernetes за отсутствием дженериков?
                                                        0
                                                        Расскажите. В код залез, но так сходу в таком большом проекте не найдешь что-то.
                                                          +28
                                                          www.reddit.com/r/golang/comments/7lzbfv/go_experience_report_generics_in_kubernetes
                                                          «In short, Kubernetes has built a type naming & identification scheme and a type registry to store each GVK. It took me a long time to identify (pun intended!) this whole thing in the codebase; after I did, I was amazed and impressed.

                                                          The core team replaced a compile-time language feature that was missing (Generics) with their home-built runtime system. And given the tools at their disposal, they did a pretty good job.»

                                                          Они де-факто форкнули язык Go и сделали себе generics сами. У них своя система типов. работающая в рантайме.

                                                          В общем, как правильно говорит Бартош Милевски: «Либо у вас динамическая типизация, либо, рано или поздно, у вас будут generics»
                                                            +2
                                                            Забавно, именно эту часть кода я читал, когда полез туда после вашего комментария.

                                                            Как правильно сказано в комментариях к той статье, дженерики не имеют к этому никакого отношения и проблему эту решить не могут, они для разных вещей предназначены. И тем более никакого форка не было. Они сделали вполне стандартную вещь — реестр типов. Каждый тип регистрируется руками в реестре. В рантайме какие-то данные по сети сверяются с этим реестром и если тип есть, то сериализуется экземпляр, либо выкидывается ошибка, мол, такого типа в реестре нет. Дженерики, не дженерики — если типа кто-то не написал, то магическим образом он в рантайме не появится. Дженерики, будучи фичей статической типизации, эту задачу не решат. Это пример того, как в язык вкорячили некий вид динамической типизации.

                                                            Я в C# тоже что-то подобное делал для сериализация протобуферов и дженерики мне там никак не помогли. Там нужна рефлексия, которая есть и в Go. Еди
                                                              +16
                                                              Мой основной посыл был в том, что многие ссылаются на kubernetes как на успех Go, своего рода флагманский проект, а они сами наткнулись на очень большие грабли с Go и обошли их способом, который, фактически, отрицает саму идею Go. И на самом деле это не флагманский проект Go, который должен доказывать, что Go — серьёзный язык, на котором можно делать почти всё, что угодно, а ровно наоборот: это большой провал Go, который доказывает, что неоPascal с CSP, созданный для решения сугубо внутренних проблем Google не может автоматически быть языком общего назначения. (я так резко отзываюсь, потому что бывший фанат Go)

                                                              Перефразируя известную фразу Филиппа Гринспена: "Каждая достаточно сложная программа на Go содержит узкоспециализированную, недокументированную, забагованную и тормознутую реализацию половины CommonLisp"

                                                              Рефлексию в Go не рекомендуют использовать без крайней необходимости и неспроста (при этом буквально все используют библиотеки, которые пропитаны ей как бисквит коньяком: encoding/json, gorilla/schema и пр.). Лучше уж нормальная динамическая типизация.
                                                                –10
                                                                Чето у вас каша в голове. Еще раз, это не имеет отношения к языку. На шарпе, яве, го, плюсах. Это решение везде будет одинаковым примерно с разной степенью извращенности реализации. Нигде это не будет красивым. Уж в плюсах точно, где даже рефлексии нет. Это стандартный шаблон, который многими применяется. Так решили разрабы кубера и это их проблемы, а не языка.

                                                                В вас и видно, что в вас говорит бывший фанат, который обиделся на что-то. Язык общего назначения был и остался. Кубернетис так и остается отличным примером, что язык применяется и тянет на себе целую индустрию, индустрию контейнеров, т.к. буквально все проекты в ней написаны на Go.

                                                                Рефлексию не рекомендуют по другой причине, озадачились бы узнать, прежде чем заявлять что-то. Причина всегда была и есть одна — пакет рефлексий сложен в работе, имеет много подводных камней и неочевидностей, поэтому можно натворить дел. Поэтому не рекомендуют туда лезть всем подряд, а только тем, кто разбирается. Рефлексия сложна по определению. И в стандартной библиотеке он, потому что он нужен и огромное количество библиотек его применяющих лишнее доказательство, что он нужен. По этой же причине рефлексию все пытаются добавить в плюсы.
                                                                  +3
                                                                  А почему рефлексия в Go есть, хотя она «сложна в работе, имеет много подводных камней и неочевидностей», а обобщённого программирования нет?
                                                                    –3
                                                                    Потому что рефлексия это пакет стандартной библиотеки, а обобщенное программирование это глава в спецификации языка. Одно можно просто не использовать и никак это нигде ни на ком не скажется, а другое фундаментальная фича языка, которая наводнит весь код на нем и окажет влияние на каждую строчку кода. Одно требует просто предоставления интерфейса до того, что и так есть в языке. А другое требует очень больших усилий в грамотном дизайне, рассмотрении всех ситуаций, взаимодействия со всеми остальными фичами языка. С последним как раз очень много проблем у всех предложений по дженерикам. Без одного просто невозможно решить многие задачи, а другое практически не требуется на практике (и опыт Go за все эти годы показывает, что дженерики полезны, но не необходимы), а во всех остальных случаях заменяется встроенными обобщенными типами.
                                                                      +8

                                                                      В общем всеми любимый Роб "его высочество император галактики" Пайк облажался с упрощением на этапе создания и теперь не знает, как туда это пропихнуть?

                                                                        +3
                                                                        Потому что рефлексия это пакет стандартной библиотеки

                                                                        Который никак не опирается на предоставляемые рантаймом средства?


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

                                                                          +3
                                                                          а обобщенное программирование это глава в спецификации языка.

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


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

                                                                          То есть разработчики просто поленились?

                                                                            0
                                                                            Нет, наличие рефлексии затрагивает весь язык. Плохо задизайненый язык или библиотека рефлексии ломают друг друга. Небольшой пример.
                                                                          +3
                                                                          Чето у вас каша в голове. Еще раз, это не имеет отношения к языку. На шарпе, яве, го, плюсах. Это решение везде будет одинаковым примерно с разной степенью извращенности реализации. Нигде это не будет красивым.

                                                                          Я ровно эту задачу в своё время решал на плюсах с темплейтами. Да, конечно, там тоже был реестр, только он был компил-тайм.


                                                                          На каком-нибудь хаскеле эту задачу решать ещё более красиво и изящно можно. С ещё большими статическими гарантиями.


                                                                          По этой же причине рефлексию все пытаются добавить в плюсы.

                                                                          Самое ироничное, что в плюсы пытаются добавить компилтайм-рефлексию, очень хардкорно опирающуюся на компилтайм-средства метапрограммирования, от constexpr до темплейтов (есть пара конкурирующих пропозалов).

                                                                          0

                                                                          Надеюсь Geth таким же прорывом Go не считают? А то у меня от этого продукта регулярно болит на работе.

                                                                            0
                                                                            пользуйтесь parity и забудьтє єтого тормозного падающего монстра!
                                                                              0
                                                                              спасибо, погуглю, но спрошу на всякий случай — он работает точно с теми же протоколами и предоставляет точно те же апи, как и geth?
                                                                              мне в идеале надо бы держать и развертывать пир, как приватную сеть с clique, так и подключаться к публичной.
                                                                                0
                                                                                нет, там есть отличия
                                                                            +3

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


                                                                            Без дополнительной аргументации и приведения конкретных примеров лично мне совсем неочевидно, что автор той статьи прав, говоря, что kubernetes пострадали от отсутствия дженериков и реализовали их заменитель.

                                                                              0
                                                                              Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
                                                                              То, что в статье названо "реализацией дженериков", не очень похоже на них.

                                                                              Чтобы реализовать генерики, надо патчить компилятор, очевидно. Тут правильнее было сказать не "реализация генериков", а "замена генериков", то есть, при наличии генериков воротить все эти рантайм-забавы бы не пришлось, при этом код был бы более надежен (т.к. фиксировались бы конкретные типы, вместо просто RuntimeObject).


                                                                              Это чисто ран-тайм операция, дженерики ее не решают.

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

                                                                                +1

                                                                                А можете привести пример, как подход, реализованный kubernetes, можно было бы заменить на дженерик для какого-то из имеющихся сценариев использования?
                                                                                В оригинальной статье этого нет — поэтому выглядит голословно. Но возможно, все так есть, просто автор решил опустить несущественные детали?

                                                                                  0
                                                                                  Как в любом языке с genericaми?
                                                                                  Десериализация посредством generic методов + рефлексии позволяет на выходе получить результирующий тип, а не его динамическое представление.

                                                                                  Типа var descriptor = getObject().
                                                                                    0
                                                                                    Извиняюсь, var descirptor = getObject<MyDeployment/>().
                                                                                      –2
                                                                                      • А где тут дженерик?
                                                                                      • Какая из проблем, которые решали создатели kubernetes, решена тут более изящно?

                                                                                      UPD: сорри, не заметил второго коммента :)


                                                                                      В общем, это все здорово, но в принципе мало отличается от вызовов в коде kubernetes. Например, (клик)


                                                                                      kubednsDeployment := &apps.Deployment{}
                                                                                      
                                                                                      kuberuntime.DecodeInto(clientsetscheme.Codecs.UniversalDecoder(), deploymentBytes, kubednsDeployment)

                                                                                      А еще есть сценарии, где тип, в который надо десериализовать, известен только в рантайме.


                                                                                      Главная сложность — реализация собственно десериализации и поддержка каталога типов, которые в принципе позволяется десериализовывать — никуда не делась (она внутри DecodeInto)

                                                                                        0
                                                                                        Главная сложность — реализация собственно десериализации и поддержка каталога типов, которые в принципе позволяется десериализовывать — никуда не делась (она внутри DecodeInto)

                                                                                        С генериками каталога никакого не нужно. В том смысле, что его за вас поддерживает сам рантйм языка, без каких-либо затрат со стороны программиста.

                                                                            0
                                                                            Можно посмотреть на репозиторий этого «форка»?
                                                                              +1
                                                                              «форк» это слишком громко сказано.
                                                                        –3
                                                                        А что великого в докере? Старая проблема, старое решение, посредственные реализация и UX. Просто его выкатила контора на G — вот хомяки и возбудились.
                                                                          0
                                                                          Докер разве не разработка dotCloud?
                                                                            –1
                                                                            Я думал основатели оттуда, не? Воспроизвели кусок допубличного кубера который занимался виртуализацией.
                                                                        +2
                                                                        да но нет
                                                                          +2
                                                                          Да, полностью согласен с автором… Всё идет именно туда. Вспоминая Фаулера с его «Программистом-фанатиком», нужно тренироваться… дома… А не на работе. И причем именно он по сути и описал ситуацию, рассмотренную автором, перейдя в стан манагеров. Им главное выкинуть в «продакшен». А какой это ценой — баги, недоработки, неэффективный расход времени. Потому и приходит выгорание. Я к чему это все. Везде важна грань. За творчество не всегда можно получить деньги, как и не всегда можно получить деньги за говно-продукт. Нельзя работать ради работы. Также нельзя работать только ради бабла. Времени на прекрасные вещи и на жизнь не останется…
                                                                            +7
                                                                            Правильно ли будет тогда программистам устроить не 8-часовой рабочий день, а шестичасовой? Потому что сейчас в некоторых отраслях (геймдев тот же) потогонка такая, что по 14 часов в сутки работают, а в моменты перед релизом могут и больше.
                                                                              +3
                                                                              И все равно потом пару лет после релиза допиливают игру то минимально адекватного состояния…
                                                                                +4
                                                                                Я вообще за 4 часа бесперерывной продуктивной работы, а потом делай, что хочешь. Как в Греции ;)
                                                                                  0
                                                                                  Вопрос только в повышении производительности труда.
                                                                                  0

                                                                                  Или на 3 рабочих дня в Google)

                                                                                    0
                                                                                    Только его не повышали 12 лет. Работать 3 дня это не повод для подражания, ИМХО
                                                                                    Если вы на работе не кайфуете, пилите что-то круто и не учитесь, то тогда это плохая работа и тогда понятное дело меньше-лучше.
                                                                                      +2
                                                                                      Если бы у меня была такая зп, что позволяет работать 3 дня в неделю и путешествовать, как этот парень — нафиг мне то повышение сдалось? Было какое-то исследование, что после определенного порога рост зарплаты перестает приносить мотивацию. Для Европы где-то на уровне 100к, штаты — 150-200к. Деньги покрывают все потребности и смысла их больше зарабатывать нет
                                                                                        0
                                                                                        1. в гугле такие зп что люди «шикуют» относительно
                                                                                        2. нафиг мне то повышение сдалось?
                                                                                          ну каждый живет как хочет. кто-то хочет уметь дом, машину. а кто-то последние деньги тратит на путешествия.

                                                                                          Если вы смотрели видео то он говорил, что перейдет на фулл-тайм когда нужно будет платить ипотеку или учебы детям.

                                                                                          он «шикует» потому что в Гугле работал. Работал бы на обычную фирму, так бы не «выпендривался»
                                                                                        3. рост зарплаты перестает приносить мотивацию

                                                                                          Деньги покрывают все потребности и смысла их больше зарабатывать нет

                                                                                          у каждого свои потребности. кому-то с любимым/ой и рай в шалаше


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

                                                                                          Я не говорю, что нужно исключительно путешествовать. Я бы проводил это время с семьей. Когда ребенок растет, ты на работе теряешь очень драгоценные моменты, которые потом не повторятся. Я работаю, чтобы покрывать свои потребности, а не жить работой. И 5 дней из 7 для меня слишком большая трата времени. Надеюсь у меня будет такая же возможность сократить это время

                                                                                            0
                                                                                            По мне так звучит как мечта бездельника, без обид

                                                                                            Чтобы не быть бездельником, нужно делать что-то разумное и осмысленное именно на работе?


                                                                                            Если я в свободное время ковыряю опенсорс или абстрактный матан — это тоже бездельничание?

                                                                                              0
                                                                                              Если я в свободное время ковыряю опенсорс или абстрактный матан — это тоже бездельничание?

                                                                                              Нет. Но это позволяют делать в Гугле на работе, AFAIK.
                                                                                              Но это не то, чем собирался заниматся Лёва (парниша из видео про жизнь Гугле) ни Crandel
                                                                                                0
                                                                                                Уже не позволяют.
                                                                                    +6
                                                                                    А что плохого в том, чтобы работать ради бабла? Я не про гнилую контору, где сидит Федя — гриб, и погоняет Ваней — солдатиком (Федя держит все знания у себя, потому что хочет бабла, Ваня делает дерьмо по той же самой причине, все совпадения случайны). Я про коллектив, где каждый делает свою часть работы за 8 часов, старается быть максимально сосредоточенным и покрыть весь код тестами, чтобы за свою работу не зафакапить, отношения хорошие, менеджеры адекватны и дают нормальные спеки. И вот каждый божий день, приходишь, работаешь и уходишь, а потом получаешь деньги в начале месяца. Да, это не стартап, но в некоторых отделах больших контор есть вполне такое здоровое отношение к жизни.
                                                                                    +7
                                                                                    Во многом согласен с автором. Разработка программ процесс творческий. Всегда надо иметь проект, работа над которым доставляет удовольствие.
                                                                                    Крик души
                                                                                    К сожалению реальность такова, что рынок требует разработчиков, которых нет. В конечном итоге это привело к целой вселенной JavaScript для JavaScript. Этот странный язык повсюду и на клиентской стороне, и на серверной.
                                                                                    Потом и этого стало мало, ведь JS сложен для восприятия и M$ сделала шикарный язык TypeScript. Этот язык в глазах многих разработчиков шикарная дама в корсете, но в моих глазах это безумный шляпник в смирительной рубашке. Ни каких больше фокусов и магии.
                                                                                    Самое же печальное в этой ситуации, что под давлением откровенно слабых разработчиков и их потребностей из мира разработки программного обеспечения вытесняются по настоящему эффективное использование ресурсов, повсюду программы, которые жрут как не в себя. Это про чудо софт написанный на базе электрона, и жирнющие сайты, которые раздувают браузер до мемов про оперативку и хром.


                                                                                      +3

                                                                                      И ладно бы это давало ускорение разработки. Так нет же. Пишут тонны бойлерплейта, переизобретают одни и те же велосипеды на новом стеке. Меняют дизайн, ещё не закончив менять предыдущий. В результате и разработка медленная, и получающиеся приложения.

                                                                                        +4
                                                                                        Пишут тонны бойлерплейта, переизобретают одни и те же велосипеды на новом стеке. Меняют дизайн, ещё не закончив менять предыдущий.

                                                                                        Это как раз творчество, которая творят творцы.

                                                                                          0
                                                                                          Там нет ни грамма творчества, к сожалению. Это просто хаос в попытке угнаться за хайп-трейном.
                                                                                        +1
                                                                                        под давлением откровенно слабых разработчиков и их потребностей

                                                                                        вытесняются по настоящему эффективное использование ресурсов

                                                                                        Всегда было интересно, почему эти две истории должны противопоставляться? Что мешает сделать эффективное использование ресурсов для откровенно слабых разработчиков?

                                                                                        +12
                                                                                        Что-то повеяло какой-то утопией. Бизнес нанимает разработчиков, чтобы зарабатывать деньги, а не двигать прогресс вперед. Прогресс вперед двигает наука, но и она на службе у бизнеса. Вот когда в основе человеческого общества будет лежать, например, стремление к всестороннему развитию человека, а не к беспорядочному заработку и трате бабла, вот тогда и можно ждать изменений. Корни в этом. А от осинки не родятся апельсинки.
                                                                                        • UFO just landed and posted this here
                                                                                            0

                                                                                            Нужно быть Маском, как минимум, да? )

                                                                                          +11
                                                                                          Я бы разделил бизнес и ИТ


                                                                                          Так а в чем проблема? Вы выбрали бизнес и сами же об этом ноете?
                                                                                          Собеседуйтесь в исследовательские отделения Google, IBM, Apple, Intel,…
                                                                                          Да даже не в ИТ: медицина, погода, ракетостроение, астрономия, прикладная физика/химия. Там у вас будет творческого программирования сколько влезет и приоритеты на качество и оптимизацию, а не выкатить побыстрее.
                                                                                            +13
                                                                                            В этом занятный парадокс программистов: с одной стороны все такие за творчество-за творчество, которому мешают злобные капиталисты своими глупыми распорядками, лишь бы только сляпать продукт для продажи, фуфуфу, как это низко, а как же полет мысли, а с другой — раз в месяц зарплату вынь да положь.

                                                                                            И возникает резонный вопрос — так ты за творчество или за бабки? Если за творчество — пожалуйста, есть множество open-source проектов, где пригодится творческий порыв. Если за бабки — делай, за что платят и не выступай. Множество же айтишников хотят усидеть на двух стульях: чтобы они, понимаешь, творили, а им за их творчество, соответственно, платили. Это еще можно понять в детском саду, но когда такое на полном серьезе излагают люди 30+, то возникают резонные сомнения в адекватности человека.
                                                                                              +2

                                                                                              И при этом большинство open source проектов без корпоративной поддержки — продукты из разряда «понять и простить», несмотря на творческий порыв и высокий полёт мысли.

                                                                                                +1
                                                                                                Инфантилизм — чума 21 века.
                                                                                                Позволить себе творчество могут только свободные (от проблем удовлетворения бытовых потребностей) люди, коих всегда считанное меньшинство.
                                                                                                Остальные, может, и стремятся к тому, да весьма ограничены в свободе выбора.
                                                                                                Высокооплачеваемый раб(отник) — всё еще раб(отник), потому что жить и творить в свое удовольствие по объективным причинам не может.

                                                                                                Строго говоря, в корне сидит причина не совсем объективная, а точнее «совсем не» — это экзистенциальная неудовлетворенность вследствие несоответствия потребностей возможностям, мелких психотравм, незакрытого гештальта и общей недозрелости личности (привет, инфантилизм из из первого абзаца).
                                                                                                  +4
                                                                                                  По моему опыту «творчество» и «бизнес» противопоставляют не самые лучшие разрабы, у которых «творчество» — это одно из двух:
                                                                                                  — бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
                                                                                                  — бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова

                                                                                                  Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.

                                                                                                  А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.
                                                                                                    +2
                                                                                                    Нужно понимать, что реальное полезное творчество не может не приносить денег.

                                                                                                    Только реальное творчество не обязано быть сиюминутно полезным.

                                                                                                  • UFO just landed and posted this here
                                                                                                    +1
                                                                                                    медицина, погода, ракетостроение, астрономия, прикладная физика/химия

                                                                                                    Без знаний в предметной области чистый программист там будет работать в лучшем случае в статусе code monkey: «закодь-ка мне эту формулу, чтобы строился вот такой график вот этим цветом».

                                                                                                      +3
                                                                                                      У возможно, это будет самое полезное, что сделает программист в своей рабочей жизни =D
                                                                                                        0
                                                                                                        Так ведь программист вне контекста предметной области — это разве что «тыжпрограммист». Что вообще общего у одного программиста и другого? Работа с логическими устройствами. А какого рода работа? Вполне конкретная — перевод команд с человеческого языка на язык логики устройства. Можно ли работать профессиональным переводчиком с английского на китайский, не зная оба языка, культуру и особенности?
                                                                                                          0
                                                                                                          Так а кто мешает взять и выучить предметную область?
                                                                                                            0

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

                                                                                                            +1
                                                                                                            Либо «сделай, пожалуйста, чтобы вот по этим формулам результат считался не два дня, а хотя бы за несколько часов». И дальше начинается уже интересная и непростая задача, которая не по силам code monkey, зато позволяет раскрыть в себе всё мастерство разработчика и безо всякого глубокого влезания в предметную область.
                                                                                                              0
                                                                                                              Забавно. Первая моя задача, которую я сделал в рамках полезного программирования — как раз ускорить имеющийся скрипт для расчета.
                                                                                                              Но там пришлось как раз проанализировать данные, методы и область и предложить решение с учетом этого анализа.
                                                                                                          +4
                                                                                                          Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов.

                                                                                                          Я примерно так отвечал когда люди говорили что хаскел сложный — сложность инструмента должна соответствовать сложности задач, как у Стаффорда Бира — сложность системы управления должна соответствовать сложности объекта управления.
                                                                                                          Был один «простой» язык — PHP, да вот оказалось что он годиться только для простых задач, а когда его начали применять в чуть более сложных, он превратился в джаву и потерял смысл.
                                                                                                            +1
                                                                                                            Я примерно так отвечал когда люди говорили что хаскел сложный — сложность инструмента должна соответствовать сложности задач

                                                                                                            Поддержу, но надо помнить, что это работает в обе стороны: странно не только делать высоконагруженные отказоустойчивые сложные системы на условном JS, но и тащить условных Haskel туда, где можно обойтись JS.
                                                                                                              0
                                                                                                              Вот не факт — если ты уже освоил полноценный инструмент, то зачем использовать убогий?
                                                                                                              Если ты уже умеешь гит, разве станешь юзать cvs в том проекте где его достаточно?
                                                                                                                0
                                                                                                                Я думаю тут играет эффект еще то, что на js что-то простенькое проще написать.
                                                                                                                Это как писать телеграм ботов на go — то, что делается за неделю, программист на питоне делает за день, просто в силу того, что питон выразительнее. А производительность тут не особо играет роль.
                                                                                                                  +2
                                                                                                                  Да, допускаю, что для каких-то прототипов, скриптов, питон может остаться, в принципе я выделяю три языковых ниши: системное программирование (Rust), прикладное с упором на надёжность/производительность (Haskell) и прикладное с упором на скорость разработки/сопровождаемость (Python).
                                                                                                                  Понятно, что любые категории это упрощение, но мне сейчас видится так. Хотя, если условный хаскел попадёт в образование и станет мэйнстримом, а значит привычным для большиснтва разработчиков, то может оказаться, что ниша условного питона очень мала.
                                                                                                                    0
                                                                                                                    Я довольно мало знаю о хаскелле, так что мне тут нечего сказать, но основная фишка питона в плане написания чего-то не очень нагруженного связана с тем, что на нем вы пишите исключительно логику, избегая всяких связываний и бойлерплейтов.

                                                                                                                    То есть вплоть до того, что когда вам нужно написать какую-то консольную тулзу, вы просто пишите питоновскую функцию, добавляете библиотеку и она сама автоматически превращается в консольную команду.
                                                                                                                      +1
                                                                                                                      Ну я тоже хаскел только немного изучал, но он тоже весьма выразительный и довольно хорошо сам выводит типы, просто во многих случаях подход другой, надо привыкать, поэтому трудно сравнивать.
                                                                                                                  0
                                                                                                                  Вы уже нашли серебряную пулю?
                                                                                                                    +2
                                                                                                                    Нет, но зачем использовать пластмассовую?
                                                                                                                      +1
                                                                                                                      А какие нужно использовать в игрушечном пистолете?
                                                                                                                        0
                                                                                                                        ) аналогия конечно не доказательство, но ок, убедили, в параллельном треде я писал про три категории языков.
                                                                                                                  0
                                                                                                                  При этом сам JS притащили уже везде где только можно.
                                                                                                                +10

                                                                                                                По поводу творчества


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


                                                                                                                По поводу "элитарного клуба" программистов


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

                                                                                                                Ваша цель – это сложность ради сложности. Чем сложнее процесс написания и чтения кода – тем лучше. Единственный смысл такого занятия – тешить своё самолюбие.


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

                                                                                                                  +3
                                                                                                                  [шутуа]
                                                                                                                  Представим себе своего рода Шаолинь: монастырь программистов — монахов. Живут на подаяния, оттачивая искусство программирования.
                                                                                                                  Ездят с лекциями. Дают платные уроки программирования.
                                                                                                                  И даже можно придумать им сверхзадачу.
                                                                                                                  Например они — последняя надежда человечества перед лицом опасности прявления злобного ИИ.
                                                                                                                  Они должны суметь с ним совладать во время великой битвы интеллектов :)
                                                                                                                    +10
                                                                                                                    Уже есть! Опенсурс же :)
                                                                                                                    Живут на подаяния, оттачивая искусство программирования.

                                                                                                                    Именно так и живет опенсурс
                                                                                                                    Ездят с лекциями...

                                                                                                                    Очень любят потусить на конфах!
                                                                                                                    И даже можно придумать им сверхзадачу.

                                                                                                                    Тоже есть — борьба с проприетарщиной, в частности виндовс-капец
                                                                                                                    0
                                                                                                                    В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов

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

                                                                                                                      … и в статьях автора сабжа.
                                                                                                                      +1
                                                                                                                      А вот тут интересная заковыка получается. Если отойти немного от темы и оглянуться вокруг, то мы увидим философию с диалектикой Гегеля и синергетику, которые пытаются понять как развиваются системы. И вот они как раз почему то констатируют что все развивается от простого сложному. Просто есть условно говоря «плохая» сложность, которая всем мешает, и «хорошая» сложность, которая служит фунадентом, для построения систем нового порядка. Переход от вычислений на бумаге и счетах к компьютерам тоже ж по своей сути был увеличением сложности, но… на нем выросли целые отрасли, поменялись экономические модели и социальные отношения. Все стало проще? Отнюдь. Увеличение сложности еще не значит что это плохо.
                                                                                                                      +3
                                                                                                                      Автор естественно хочет себя реализовать. Хочет оставить какой-то след, который будет жить самостоятельной жизнью и иметь черты автора, что понятно. Это важная потребность человека. Корпоративное программирование это совсем не то место, где это случается. Хотя по началу кажется, что это именно то самое место. А нет. Если автор хочет себя реализовать в программировании, он должен делать что-типа Skype-а, каким он был во время своего появления; какое-то уникальное очень полезное ПО. И скорее всего свое.
                                                                                                                      Часто девиз бизнеса — безобразно, но единообразно. Но основное противоречие в том, что автор пытается реализовать себя в «работе на дядю». Дядя лучше знает, что ему нужно. И готов подавлять позывы рабочих к самореализации требованиями и деньгами. Дядя реализовывает себя.
                                                                                                                      Но кое-что может остаться кроме денег. Это квалификация, которую могут оценить другие и которая может открыть новые возможности. Если же и этого не остается, то из такого места надо точно бежать, если там не платят 100тысячмиллионов, использую которые можно себя реализовать или потом или в свои проектах.
                                                                                                                        0
                                                                                                                        Да, да и еще раз да.

                                                                                                                        Пришел к подобным выводам 7 лет назад и ушел в сисадмины. Сисадмин может себе позволить программировать для себя.
                                                                                                                        Так что теперь программирование это или скрипты для работы или хобби. Вот сейчас решил джаву вспомнить.

                                                                                                                        PS Ну, ладно. И за большими деньгами ушел. Тоже. ;-)
                                                                                                                          +7

                                                                                                                          От созидания в эксплуатацию?)


                                                                                                                          И где это у админов большие деньги? В среднем меньше чем у кодеров

                                                                                                                            0
                                                                                                                            У САПеров больше. И в среднем и в частном.

                                                                                                                            В том то и дело. Текущее программирование уже как бы и не созидание.
                                                                                                                            Как бы кратко сформулировать то.
                                                                                                                            Есть правила как назвать переменные, как назвать функции. Как построить работу модуля\программы\чего угодно. Есть правила для внешних интерфейсов для внутренних. Правила для всего. Делать какое то изящно-красивое решение — нельзя. Мало того что оно как правило больше времени займет, так и не поймет потом никто. Поэтому только самое простое, только в лоб.

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

                                                                                                                            И самое ужасное — я отлично понимаю, что так и должно быть. Что все эти правила обеспечивают и понимание другими людьми моего кода, и мое понимание чужого, и я через год благодаря этим правилам пойму что сам же написал. И меньше ошибок будет и прочее прочее.

                                                                                                                            Кратко не получилось.
                                                                                                                              0

                                                                                                                              Тяжело не согласиться. Но это так только в прикладном программировании, а оно не одно в индустрии.


                                                                                                                              Про "виртуально" написанный код. Ну так виртуально много чего существует, просто мы еще этого не знаем. Почему и корректен именно термин "открытие" в науке. Все примеры решены, гипотезы доказаны. Это весь мир так устроен

                                                                                                                          +21
                                                                                                                          Это вам не роман, какой к чёрту авторский стиль?!

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


                                                                                                                          Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар. Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже».

                                                                                                                          Напомню, что код пишется для людей. Если кроме вас его никто не может понять, то бизнес зависит от того, как успешно вы уворачиваетесь от автобусов. Завтра вы написали заявление по собственному — код можно выкидывать.


                                                                                                                          Впрочем, вы сами написали это ниже:


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

                                                                                                                          Не можете написать просто и эффективно — страдайте.


                                                                                                                          Они не добавили дженерики в Go, потому что дженерики — сложные.

                                                                                                                          • В Go 2 дженерики будут
                                                                                                                          • Те, кто хотел, использовали кодогенраторы.
                                                                                                                          • Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.
                                                                                                                          • C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
                                                                                                                            +1
                                                                                                                            Я так понял автора, что он делал упор не на то, что код должен быть витиеватым, а на том, что оптимальность и стиль конечного продукта неважен в современном бабломире.
                                                                                                                            Я лично за единую архитектуру проектов в рамках конкретного бизнес-решения (мне нравится DDD).
                                                                                                                              +1
                                                                                                                              Именно. Программист — инженер, а не писатель

                                                                                                                              Мне ближе метафора «строитель», она нагляднее.
                                                                                                                                +16
                                                                                                                                В Go 2 дженерики будут

                                                                                                                                Вот когда будут, тогда и поговорим.
                                                                                                                                  –8
                                                                                                                                  И вероятность их появления все еще небольшая. Дженерики все еще слишком сложные и их ценность это не оправдывает.
                                                                                                                                    +3

                                                                                                                                    Подскажите, а сложные для кого?


                                                                                                                                    Для программистов? Мне кажется, концепция программирования с каналами и горутинами, которая используется в go куда сложнее, чем "ой, мы можем параметризировать типы".


                                                                                                                                    Для разработчиков языка? Очень грустно, учитывая, что все остальные языки довольно легко это освоили.

                                                                                                                                  +6
                                                                                                                                  Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.

                                                                                                                                  А вы точно знаете, что такое дженерики и зачем они нужны? И как бы, зачем вы требуете их в питоне?


                                                                                                                                  Ну и алсо, в питоне есть дженерики, как только там ввели подсказки по типам.


                                                                                                                                  C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.

                                                                                                                                  И сколько из-за этого боли испытывают java программисты, вы не представляете. И даже есть очень долгоиграющий проект, который пытается это пофиксить, но все никак.

                                                                                                                                    0
                                                                                                                                    А вы точно знаете, что такое дженерики и зачем они нужны?

                                                                                                                                    Я пишу на шарпе и не пишу на Go.


                                                                                                                                    Ну и алсо, в питоне есть дженерики, как только там ввели подсказки по типам.

                                                                                                                                    Они не энфорсятся интерпретатором — их по сути(т.е. они даже видны в рантайме, чем пользуются некоторые DI-фреймворки, но это скорее сайд-эффект) нет, если не учитывать сторонние линтеры.


                                                                                                                                    И как бы, зачем вы требуете их в питоне?

                                                                                                                                    Их и не может быть в питоне в чистом виде — нет нормальных типов => нет дженериков. На питоне делают руками то, что реализует компилятор и рантайм в том же C# и добиваются успеха, выдавая сложный и рабочий код — точно так же смогут и в Go.


                                                                                                                                    Собственно, по этой причине я не согласен с автором.


                                                                                                                                    Неизмеримое количество нетривиального и полезного софта написано вообще на сях, без дженериков(да, есть макросы, но всё же), вывода типов, исключений, чего угодно — посредственные разработчики просто бы просто не вытянули такие проекты. Опенсорсного, кстати — это не какой-то большой дядька решил, что они сэкономят бюджет, а выбрали сами девелоперы.


                                                                                                                                    На F# же, который автор поставил в теги и, скорее всего, считает хорошим языком, я слышал только о FAKE, который не то, чтобы сильно популярен или не имел аналогов.


                                                                                                                                    Где все те гениальные проекты, которым мешает простота языка и грязные решения? А нет их, не подтверждает реальность слова автора.

                                                                                                                                      0
                                                                                                                                      Их и не может быть в питоне в чистом виде — нет нормальных типов => нет дженериков. На питоне делают руками то, что реализует компилятор и рантайм в том же C# и добиваются успеха, выдавая сложный и рабочий код — точно так же смогут и в Go.

                                                                                                                                      Эм… что? То есть помимо того, что нормальные типы то у нас есть, у нас строгая типизация, все-таки, в питоне вы не делаете это ручками. У вас просто нет типа у переменной (потому что типизация динамическая), а следовательно нет нужны в дженериках, потому что у вас все работает как-будто под дженериками.


                                                                                                                                      Грубо говоря, если на C# без дженериков вы бы писали как-то так (псевдокод):


                                                                                                                                      Array x = new Array();
                                                                                                                                      int a = 5;
                                                                                                                                      x.add(a);
                                                                                                                                      assert a == castToInt(x[0])

                                                                                                                                      То в питоне приведение типов вам не нужно, потому что при добавлении в список тип переменной не затирается.

                                                                                                                                        –1
                                                                                                                                        Эм… что?
                                                                                                                                        То есть помимо того, что нормальные типы то у нас есть, у нас строгая типизация, все-таки
                                                                                                                                        в питоне вы не делаете это ручками.

                                                                                                                                        Вы делаете:


                                                                                                                                        • Обеспечиваете типобезопасность.
                                                                                                                                        • Реализуете менее очевидные вещи, которые достаются с дженериками. В C#, например, все DI контейнеры выставляют наружу интерфейсы уровня

                                                                                                                                        container.RegisterService<TInterface, TImplementation>()
                                                                                                                                                  where TImplementation : TInterface;
                                                                                                                                        
                                                                                                                                        container.GetService<TInterface>();

                                                                                                                                        • Язык гарантирует совместимость типа регистрируемых интерфейса и реализации за счёт generic constraint.
                                                                                                                                        • Ни один из методов не требует передавать типы в виде аргументов — информация о типе доступна в рантайме через рефлексию / typeof(тип-параметр).
                                                                                                                                          • В java так нельзя из-за type erasure

                                                                                                                                        В том же C# можно написать что-то вроде


                                                                                                                                        class GenericAddList<T> : List<T> where T : new(){
                                                                                                                                             public T AddNew(){
                                                                                                                                                    var t = new T();
                                                                                                                                                    this.Add(t);
                                                                                                                                                    return T();
                                                                                                                                             }
                                                                                                                                        }
                                                                                                                                        
                                                                                                                                        ...
                                                                                                                                        
                                                                                                                                        var list = new GenericAddList<SomeClass>();
                                                                                                                                        var newValue = list.AddNew();

                                                                                                                                        Т.е имея информацию о типе для дженерика создавать инстансы объектов. Всё это можно сделать в питоне, но придётся в явном виде передавать типы и интерпретатор даже не ругнётся, если где-то типы окажутся несовместимы / код упадёт где-то дальше.

                                                                                                                                          0
                                                                                                                                          Почти все, что вы написали в целом относится к вопросу «динамическая или статическая типизация» на мой взгляд.

                                                                                                                                          Ну, исключая тот факт, что в питоне вам не нужно передавать тип, вы можете просто достать тип из объекта.
                                                                                                                                            –1
                                                                                                                                            >В java так нельзя из-за type erasure
                                                                                                                                            Вообще-то можно. Типы полностью никуда не исчезают, они всегда в рантайме были, хотя не везде, да и достать их не всегда просто. Гуглите например guava typetoken.
                                                                                                                                      0
                                                                                                                                      C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.

                                                                                                                                      С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?

                                                                                                                                      Проблема (была?) с дженериками в Go в том, что дизайнеры говорят, что это зло, а не то, что: «ребята, блин, неуспели, скоро допилим, ждите»

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

                                                                                                                                      Карл, зачем в динамических языках дженерики?
                                                                                                                                        0
                                                                                                                                        С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?

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

                                                                                                                                      +20
                                                                                                                                      Не понимаю, что плохого в простом коде? Простота — это красота. Программа должна быть логичной, как «Начала» Евклида. Не испытываю симпатии к «сумрачным гениям», которые вместо того, чтобы сделать нормально, начинают изобретать какие-то только им понятные подходы.
                                                                                                                                        +2
                                                                                                                                        Простота — это красота.

                                                                                                                                        Это абсолютно верно. Проблема начинается, когда упрощение работает против выразительности и безопасности. К тому же язык программирования чем-то схож с языком естественным, на нем тоже человек выражает какие-то свои мысли. И если тебе всё время нужно говорить про «снег», то хотя бы одно слово для этого нужно вместо «то, что холодное, белое и падает с неба». Это я к тому, что упрощение хорошо только до некоторого предела, гоу на мой взгляд эту грань перешел.
                                                                                                                                        +2
                                                                                                                                        Проблема известная — ремесло vs творчество. В ремесле как правило деньги, в творчестве как правило свобода. Сочетание денег и свободы можно поискать в стартапе, но обычно такое длится не более полугода. Дальше либо начинается ремесло, либо инвестор перестает спонсировать «творцов».
                                                                                                                                          0
                                                                                                                                          >> Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока.

                                                                                                                                          GitHub / open source, или это не то?
                                                                                                                                            +10
                                                                                                                                            Не могу согласиться с автором по нескольким причинам.
                                                                                                                                            Во-первых неправильные вводные:
                                                                                                                                            в гигантскую индустрию, где работают сотни миллионов людей.

                                                                                                                                            Возможно автор забыл что на земле всего 7.5 млрд человек. Из них примерно 50% нетрудоспособное население. Остается всего давайте скажем 3.5 млрд. «сотни миллионов» предполагают хотя бы «2 сотни млн». То есть Двести Миллионов программистов. Вы уж извините, но мои оценки намного скромее, дай бог если на планете есть 10 млн ИТшников.
                                                                                                                                            Но мне говорят — супер решение не нужно. Нужно обычное.

                                                                                                                                            Примерно такая же попытка обобщать на некотором количества личного опыта. В программировании, как и в практически любой отрасли, есть «гении» и рабочие пчелы. Да пчел больше. Но никто не отменял и не мешает автору или любому из нас стать «гением». Именно они меняют индустрию год за годом. Именно они пишут новые языки программирования и изобретают новые концепты. И уже рабочие пчелы либо принимают предложенныеконцепты либо отвергают их.
                                                                                                                                            Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом.

                                                                                                                                            Это относится далеко не ко всем «пчелам» и совсем не относится к «гениям».
                                                                                                                                            А мы сейчас живем в то время, когда «хорошо сделанное» и «прибыльное» — разные вещи.

                                                                                                                                            Это не новое время. Так было всегда. Сделать мало — надо еще донести продукт до потребителя, обосновать справедливость цены, продемонстрировать удобство для пользователя, доказать что «хорошо сделано» и в общем случае что цега-качество как минимум не хуже чем у конкуренттов. Все это основы торговли и экономики и так было всегда с момента изобретения денег и появления хоть какой-либо альтернативы и конкуренции.
                                                                                                                                            Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.

                                                                                                                                            Это уже как я сказал сделано, просто не так радикально. Когда гиганты индустрии работают над новыми чипами, языками, системами, протоколами, они не ограничены только потребностями бизнеса, они делают что-то просто потому что они верят что это хороший продукт. Да иногда они бросают какие-то не «выгоревшие» продукты и проекты.
                                                                                                                                            Но если вы имеете в виду радикально не разрешать бизнесу программировать. Это нео-цифровой-тоталитаризм? Вы хотите продавать или давать свой код бесплатно только тем кто «заслужил»? и только в «квадратной» упаковке? вы серьезно? У меня теряется дар речи от такого предложения.

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

                                                                                                                                            Моя позиция состоит в том, что есть области где любые нестандартные и творческие решения очень даже приветствуются. Если вам надоело быть «машиной» для программирования, просто поищите другие проекты — их много. Достаточно много.

                                                                                                                                            Просто вы можете обнаружить что там уже довольно высокий порог входа. Что все о чем вы «мечтали» уже есть.

                                                                                                                                            Или начните свой проект. Напишите свой язык программирования. Не забывайте что Linux был создан студентом. А PHP был по сути полускриптом для личного пользования. У вас есть что-то что отражает ваши «творческие» порывы в программировании? просто доведите это до какого-то состояния и положите на гитхаб. Вы очень удивитесь насколько это может оказаться интересным окружающим.

                                                                                                                                            Я не согласен с Вами и Вашими выводами. На мой взгляд, индустрия делает отсев ненужного в автоматическом режиме и делает это хорошо. Места для творчества много просто не надо искать его в поддержке сайтов на WordPress или в пресловутом 1С. Если ваш последний опыт не очень вас удовлетворяет — не делайте выводов об индустрии и бизнесе. Просто сформулируйте что именно вам хотелось бы делать и ищите подходящий проект, поверьте выбор огромен и возможно где-то сейчас ищут именно Вас!
                                                                                                                                              +5
                                                                                                                                              Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.

                                                                                                                                              Например, проблему отсутствия generic'ов — одинаковым копипастом. Хотя постойте, некоторые (судя по комменту выше) используют кодогенераторы.


                                                                                                                                              Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.

                                                                                                                                              Каким образом будет финансироваться программирование ради программирования?


                                                                                                                                              Программируя, я хочу заниматься творчеством. Хочу иметь огромное число опций, когда дизайню систему. Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение.

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

                                                                                                                                                –1
                                                                                                                                                Например, проблему отсутствия generic'ов — одинаковым копипастом.

                                                                                                                                                А для многих других проблемы такой нет и вовсе. go generate так вообще ниразу не трогал. В это людям обычно сложно поверить, особенно живущих только в мире сложных и больших языков, но встроенных дженерик массивов и словарей достаточно практически для всего. Я дженерики конечно жду в Go 2, но мне лично все равно, будут ли они или нет. Есть куда более важные вещи, которые стоит сделать в новой версии. И если дженерики надо принести в жертву ради этого, то будут только за. Потому как Go 2 хоть и делают, но раздувать спецификацию до размеров плюсов никто не собирается. Будет добавлена пара тройках больших фич.
                                                                                                                                                +7
                                                                                                                                                И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение. Но это же обман!

                                                                                                                                                Смысл того, зачем Go отрезал от себя намеренно как больше частей, это получить небольшое число фич, но которые идеально совмещаются и все ортогональны друг другу. Нет ничего хуже, чем новая фича в языке, которую надо гвоздями прибивать к другим конструкциям, потому что кто-то не думал обо всех вариантах ее приминения. Это имеет далеко идущие последствия, когда библиотеки находятся в постоянном подвешенном состоянии и экосистема так и не сходится на чем-то одном. За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.

                                                                                                                                                В конечном итоге, Go это всего лишь язык. Никого он ничем не ограничивает там, где это действительно имеет значение. Он позволяет написать абсолютно все что угодно бесчисленным числом способов.

                                                                                                                                                Go — это бизнес-эффект, а не инженерное решение

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

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

                                                                                                                                                Продолжать можно долго, но почти во всем у вас наблюдается явное непонимание зачем это все сделано. Весь пост пропитан какой-то джуниорской наивностью. Иначе вас бы не удивляло требование переписать слишком сложный сервис, пусть чуть медленнее. Это очевидная вещь.
                                                                                                                                                  +2
                                                                                                                                                  За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.
                                                                                                                                                  А можно примеры? Ну кроме стандартной проблемы вызова асинхронного кода из синхронного. А то как-то ни разу в моей практике реальных проблем не было.
                                                                                                                                                    +2
                                                                                                                                                    Тоже в недоумении, пожалуй только обработка эксепшенов при вызове Wait() из синхронного кода немного корявая. Ну и к continuation нельзя невежд подпускать, обернуть все в библиотечные вызовы и пусть пишут простые async/await.
                                                                                                                                                  +2
                                                                                                                                                  Ищите позиции исследователя (research engineer), и у вас будет определённая свобода. Говорю по собственному опыту.
                                                                                                                                                  А так все верно, и про творчество, и про безликость.
                                                                                                                                                    0
                                                                                                                                                    Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.


                                                                                                                                                    Мне кажется, то что вы предлагаете, хорошо находит свое отражение в OpenSource. В котором бизнес не ставит ограничения по срокам. В тоже время, в OpenSource, для того, что бы оставаться конкурентоспособным стремятся решить проблему, в первую очередь качественно а не быстро.
                                                                                                                                                      0
                                                                                                                                                      в первую очередь качественно а не быстро.

                                                                                                                                                      Большое заблуждение и обобщение. Возьмем gitlab. Во многом образец open source продукта, только вот его приоритеты это набивание продукта фичами, а не исправление проблем. И исправлению ситуации не способствует даже то, что у них полно клиентов, которые им платят деньги и жалуются на проблемы постоянно.

                                                                                                                                                      Напротив, ненавистный golang именно по такой модели и разрабатывается. Очень осторожная разработка с предельным вниманием к качеству кода и большими сроками стабилизации продукта до того, как будет выпущена новая версия. 3 месяца разработки, 3 месяца тестирования и исправления проблем, релиз. Только вот автор там тоже будет не кстати. Там никому не нужно творчество и фантазия ради творчества и фантазии. Нужны простые и эффективные решения. А сложное, даже если оно быстро и полезно, порой и не примут. Такое уже было неоднократно. Недавно вон хотели более хитрый алгоритм сортировки добавить, но большая сложность кода стала препятствием. Не оправдывал прирост в скорости такую сложность.
                                                                                                                                                        0
                                                                                                                                                        Да, согласен. Но так продукт бездумно набивается «от души». Ведь куда приятнее запилить что то новое а не фиксить баги =) А большое количество клиентов так как они почти монополисты на этом ранке. Ну и потом… не смотря на то, что я не владею большой информации по развитию этого проекта, смею предположить что большое количество клиентов приводит к появлению так называемых «спонсоров» которые «спонсируют» не сам проект а определенные фичи, которые там в большом количестве появляются. А это, в свою очередь, как раз таки и сваливает проект от теплого и лампового open source в сторону ужасного и требовательного бизнеса. В этом плане golang наверное ближе к идеологии opne source чем gitlab. Имхо.
                                                                                                                                                          0
                                                                                                                                                          Это тоже. Жалоб среди пользователей бесплатной версии, что все больше внимания уделяется фичам, которые попадают только в платную версию, тоже достаточно. К тому же, если раньше было две версии, платная и бесплатная, то теперь там несколько уровней платности и логика, по которой фичи отбираются в тот или иной уровень, порой непонятна совершенно. Оправдание всегда одно, мол, фичи в платную версию идут те, которые для небольших команд ненужны. А если команда большая, то платите. Явно ноги растут из клиента, который попросил фичу, которая и была бы полезна небольшим командам, но некрасиво будет раздавать ее бесплатно. Так то gitlab конечно крут, конкурентов у него наверное действительно нет в плане бесплатных решений, но такая ситуация меня печалит.

                                                                                                                                                          Особенно проблемы с недоделкой фич. Многие вещи бросают на пол пути и в итоге оказывается, что, например, новый замечательный репозиторий контейнеров не чистит за собой и забивает людям диски терабайтами мусора. В планах было это сделать к 11.6, которая вышла на днях. План сорвался, т.к. и так туча фич запланировали. Сдвинули к 11.7. А появилась эта фича в 8.8, полтора года назад. Когда они это реально исправят черт его знает, а ведь это очень большая проблема.
                                                                                                                                                      +1

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


                                                                                                                                                      Проблема с «другими» задачами в том, что прочитав книгу “Go за 21 день» их не решить. Надо много знать за пределами программирования. Например, знать какой-то бизнес, или разбираться в математике и решать с помощью своих знаний задачи. Знание Go и очередного мега фреймворка никаких задач не решает и если это все, что вы знаете, то бизнес поставит вас решать типовые задачи, не требующие творчества и спец. знаний.

                                                                                                                                                        +21
                                                                                                                                                        Честно говоря я не понимаю откуда такое одобрение у этого поста.
                                                                                                                                                        Начиная с сорри мини-выпиндрежа про «следите за пальцами», ханжеских рассуждений про порнуху через впн и пиратство, заканчивая «Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации» — wtf, это не идеализм, это банальное не понимание реальности. В реальности ты волен выбирать работать тебе на бизнес за деньги, или сосать лапу в опенсорсе, или комбинировать так, чтобы максимально удоволетворять свои потребности. Да даже не понятно что тут обсуждать и как это толком связано с названием «Безликий код убьет программирование, и ничего мы с этим не сделаем».
                                                                                                                                                        ЗЫ Кто-то должен был это написать — заметка ни о чем.
                                                                                                                                                          0
                                                                                                                                                          ханжеских рассуждений про порнуху через впн и пиратство

                                                                                                                                                          Оффтоп, но достали уже употребления слов без понимания их значения.
                                                                                                                                                          Есть пруфы, что автор смотрит порнуху через VPN или пиратит? Нет? Тогда где тут ханжество?
                                                                                                                                                            +1
                                                                                                                                                            Точно не путаете ханжество и лицемерие?
                                                                                                                                                              0
                                                                                                                                                              Это практически синонимы. Только ханжеством почему-то часто называют просто осуждение поступков, которые называющим кажутся приемлемыми. Это как если бы серийный убийца называл ханжеством осуждение убийства.
                                                                                                                                                                0
                                                                                                                                                                Не совсем понял. Мне из определения ханжества нравится строчка про «Крайность в осуждении аморальности». По-моему, она тут прямо на лицо, в демонстративной форме. Не знаю как там у других, но просмотр таких вещей, а также обход абсурдных блокировок в стиле DMCA просто отличным применением VPN, наравне со многими другими вещами.
                                                                                                                                                                  0
                                                                                                                                                                  А мне не нравится это строчка, хотя бы потому, что лицемерие объективно, а «крайность» субъективна.
                                                                                                                                                                  +1
                                                                                                                                                                  Эка вы лихо просмотр порно с убийством в одну линию поставили…
                                                                                                                                                            +7
                                                                                                                                                            Искусство нуждается в самоограничении. Хорошие композиторы не жалуются, что нот всего 7. Архитекторы как фигачили всё одинаковыми прямоугольными кирпичами со времён Римской империи, так и до сих пор фигачат. В балете как минимум с XVI века одни и те же характеры и па. Абстракционисты все умели в пропорции и композицию, так же, как до них импрессионисты − в цвета.

                                                                                                                                                            Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.
                                                                                                                                                              0
                                                                                                                                                              Я бы сказал бы, что нот таки больше семи.
                                                                                                                                                              В хроматическом звукорядке, который используется в современной музыке, рассматривают 9 октав, каждая из которых состоит из 12 нот.
                                                                                                                                                              Семь нот — это лишь способ записи музыкального произведения, к которому добавляются знаки альтерации и ключи у нотного стана.
                                                                                                                                                                0
                                                                                                                                                                А бит имеет аж два состояния — вот уж простор для творца. Но почему от машинных кодов отказались
                                                                                                                                                                +1
                                                                                                                                                                Пусть все решит естественый отбор.
                                                                                                                                                                Пусть клмпании, желающие «урвать кусок прямо сейчас» его получат, и с ним в зубах сдохнут. Не мешайте им убивать себя.
                                                                                                                                                                А сами пока пилите свои проекты по всем правилам.
                                                                                                                                                                Проект жив только в руках Мастера.
                                                                                                                                                                В руках «эффективного менеджера» он умирает.
                                                                                                                                                                  +2
                                                                                                                                                                  Какой бизнес, такое и IT. Иметь программу более надёжную, чем сам бизнес, бессмысленно. Это будет ситуация «без штанов и в шляпе».
                                                                                                                                                                  90% компаний закрывается в течение первого года, 3% продолжает существовать более 3 лет.
                                                                                                                                                                    +2
                                                                                                                                                                    Боюсь, что изобретение общего искусственного интеллекта убьет программирование намного раньше.
                                                                                                                                                                      +4
                                                                                                                                                                      Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.

                                                                                                                                                                      Философия языка — создавать одинаковые проблемы, чтобы их решали одинаковым образом.

                                                                                                                                                                        +1
                                                                                                                                                                        Видел я таких, «творческих» программистов. И инженеры из них херовые, и пользы для бизнеса не сильно много.
                                                                                                                                                                        Не надо оправдывать говнокод творчеством. Программы надо писать понятно, прозрачно, эффективно, быстро и стабильно. Ваш же пост все это подводит под хотелки бизнеса и кровавых топ менеджеров, и вообще, мол, это все от лукавого.

                                                                                                                                                                        А знаете, в чем дело? В том, что вы сами признавались n публикаций назад, что Вы вечный мидл. Максимализм и показушничество.

                                                                                                                                                                        PS. Если что, я и сам Go не люблю, но по другим причинам. Основной язык С++
                                                                                                                                                                          –1
                                                                                                                                                                          Творчеством занимаются маркетологи, дизайнеры и специалисты в предметных областях, которые формируют концепцию продукта. Программисты занимаются переводом этих фич в машинный язык на более низком уровне.

                                                                                                                                                                          Может быть автор ошибся с профессией: думал, что программист — это такой сумрачный гений и рок-звезда, который решает всё: от списка фич продукта до списка флагов компилятора, а на деле оказалось, что программист — это что-то вроде переводчика, который может переводить, но не может ничего сказать самостоятельно, поскольку самостоятельно говорят другие — компетентные — люди.
                                                                                                                                                                            0
                                                                                                                                                                            Я согласен с автором в том, что программирование идет по пути бизнеса, но это не программирование, а человечество в целом. Тем не менее, мне кажется, что написание «безликого» кода, хоть и удовлетворяет нуждам бизнеса и всячески им поддерживается, но никак не лишает профессии программиста творчества. Продукт работы программиста не строки кода, которые могут быть безликими, а цельная программа. Это как сводить рисование к тому, как водить кисточкой. Творчество не в том, что ты водил кисточкой каким то особым способом а в том что ты этой кисточкой создал что то новое.
                                                                                                                                                                              +3
                                                                                                                                                                              большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.

                                                                                                                                                                              И это маркетинговый обман для того, что бы оправдать синтаксическую бедность языка. То есть исключая абсолютную глупость утверждения в плане логики работы кода и прочего, у golang даже синтаксис иногда позволяет сделать одного и тоже разными способами (тут есть немного примеров). Просто не ведитесь на это. Сюда еще можно докинуть управление зависимостей.


                                                                                                                                                                              Go — это бизнес-эффект, а не инженерное решение. Он сам себе противоречит. Вот он хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности. Дженерики существуют именно ради надёжности, чтобы предвосхищать потенциальные баги dev-time. И да, они довольно сложны.

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


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

                                                                                                                                                                                0

                                                                                                                                                                                Думаю, вы полностью правы. Go создан программистами старшего чем мы поколения. Со своим видением и опытом. Можно сказать, что этот опыт они включили в язык как набор шаблонов и требований.


                                                                                                                                                                                *Дженерики не приехали :) Их еще пару лет будут аккуратно смотреть и пробовать.

                                                                                                                                                                                  –2
                                                                                                                                                                                  у golang даже синтаксис иногда позволяет сделать одного и тоже разными способами

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

                                                                                                                                                                                  И никакого маркетингового обмана в этом нет. Для кого бедность языка, а для кого прекрасный дизайн языка, позволяющий писать ясный код. Возможность писать одно и тоже разными способами для меня как раз признак низкого качества языка и нагромождения фич. И го был бы еще лучше, если бы в нем, например, убрали new.

                                                                                                                                                                                  Тоже самое с управлением зависимостями. Одна из самых прекрасных фич языка. Сколько проблем и гемора предотвращено просто грамотным дизайном модулей. И проблемы тут возникают только тогда, когда приходишь с другого языка, где можно творить что душе угодно и не важно, чем это обернется в будущем.
                                                                                                                                                                                    +1
                                                                                                                                                                                    И никакого маркетингового обмана в этом нет. Для кого бедность языка, а для кого прекрасный дизайн языка, позволяющий писать ясный код. Возможность писать одно и тоже разными способами для меня как раз признак низкого качества языка и нагромождения фич. И го был бы еще лучше, если бы в нем, например, убрали new.

                                                                                                                                                                                    Ну, фиг с ним с синтаксисом. Но на уровне логики приложения у вас такого не получится достигнуть в целом никогда. А синтаксические трюки дело десятое, на мой взгляд.


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

                                                                                                                                                                                    Я прошу прощения, это вы про go mod, который появился сравнительно недавно, а до этого полный трешак с go get и отсутствием управления зависимостей. Причем каждый другой новый язык с самого начала вводит какие-то пакеты или модули, а вот golang решил отличится.

                                                                                                                                                                                      –2
                                                                                                                                                                                      Ну, фиг с ним с синтаксисом. Но на уровне логики приложения у вас такого не получится достигнуть в целом никогда. А синтаксические трюки дело десятое, на мой взгляд.

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

                                                                                                                                                                                      Я прошу прощения, это вы про go mod, который появился сравнительно недавно, а до этого полный трешак с go get и отсутствием управления зависимостей

                                                                                                                                                                                      И про то, и про другое. Это чуждо может быть для других языков, но go get привил подход, когда мастер ветка всегда стабильна. Что go mod к этому добавил, это версионирование, которого действительно не хватало. Каждый решал это сам — сабмодулями в гите, сторонними решениями вроде dep и т.д. В плане тулинга был пробел и тут явно видны ноги гугла с его монорепой, а вот сам дизайн модулей — он сделан прекрасно и одна из лучших фич языка.

                                                                                                                                                                                      Сейчас вот главное, чтобы вендоринг оставили такой, какой есть. А то вместе с go mod убрали его поддержку, но под напором общественности вернули. Правда в каком-то корявом виде с необходимостью передать флаг, чтобы включить ее.
                                                                                                                                                                                        +1
                                                                                                                                                                                        Это чуждо может быть для других языков, но go get привил подход, когда мастер ветка всегда стабильна

                                                                                                                                                                                        Хах, нет. Просто go get привел к версинности по коммитам, а в куче проектов как мастер ветка собирается через раз, так это и происходит. В хороших проектах проектах так и без специальных тулзов делают.

                                                                                                                                                                                          +3
                                                                                                                                                                                          но go get привил подход, когда мастер ветка всегда стабильна.

                                                                                                                                                                                          Вы рассчитываете на определенный API определенной версии библиотеки, и при этом ссылаетесь на ее master branch? Звучит безумно. Он то может быть стабильным, только вот обратной совместимости API никто не гарантирует. Меня это оттолкнуло от GO с самого начала, вместе с идиотским GOPATH и отсутствием эксепшенов. Радует, что первый пункт уже устарел, надеюсь что решили и остальные проблемы.
                                                                                                                                                                                    0
                                                                                                                                                                                    Согласен с аффтором… любое укрупнение языков приводит к унификацию и ограничению возможностей разработки… я в принципе не являюсь долбоящером программистом… я инженер… пишу код по мере необходимости, быстро и то что нужно… долго работал в C# скажем так очень просто и много возможностей… однако в определенный момент стало ясно что на целевой платформе на C# слишком границы возможностей сужены… ушел на С++ и оказалось что можно творить то что раньше и не снилось… да вариантов решения одного и того же множество но в этом и прелесть можно создать именно то что нужно а не выбрать из готовых шаблонов…
                                                                                                                                                                                      0
                                                                                                                                                                                      А я всегда говорил что сначала архитектура, потом парадигма, а потом язык программирования… если уж говорить о ЯП
                                                                                                                                                                                        +1

                                                                                                                                                                                        Не могу согласиться с утверждением, что сложность нужна для надежности.
                                                                                                                                                                                        И это не изобретение Go — ограничение языка для более простой и надежной работы. Это просто потомок альтернативной ветви эволюции императивных языков Modula/Oberon/Pascal. В чем-то это детё Вирта. А он всю жизнь именно борьбе со сложностью за надежность и посвятил. Пройдитесь по мшистым форумам Оберона, там все несколько иное, но надо отдать должное, народ пишет умные и надежные системы.

                                                                                                                                                                                          0
                                                                                                                                                                                          Как все запущено. Вам к терапу.
                                                                                                                                                                                            0
                                                                                                                                                                                            Я не имею ничего против дженериков, но мне до сих пор не понятно, почему в какой-то момент времени их наличие стало критерием качества языка?
                                                                                                                                                                                            Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.
                                                                                                                                                                                              +2
                                                                                                                                                                                              Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.

                                                                                                                                                                                              Если вы не можете нормально писать с перегрузкой функций, то вы, очевидно, не сможете писать нормаль и с ней. Поэтому давайте называть функцию print, print1, print2.


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

                                                                                                                                                                                                –4
                                                                                                                                                                                                Вы говорите «нужны» там, где следует говорить «удобны».

                                                                                                                                                                                                А вообще мне очень нравится ваше определение: нужны для универсальных контейнеров, функции и прочей фигни.
                                                                                                                                                                                                  +3
                                                                                                                                                                                                  Вы говорите «нужны» там, где следует говорить «удобны».

                                                                                                                                                                                                  Они именно нужны. Потому что если их нет, вы начинаете их эмулировать путем приведение типов туда и обратно.

                                                                                                                                                                                                    –2

                                                                                                                                                                                                    Или, тяжело представить, придумаю, как обойтись без этого?
                                                                                                                                                                                                    Не это ли та свобода на отсутствие которой так сетует автор?
                                                                                                                                                                                                    Не в том ли проблема, что зачастую дженерики (хоть и, повторюсь, я считаю их хорошим инструментом) в руках непризнанных творцов становятся просто средством латания кривой архитектуры?


                                                                                                                                                                                                    Хорошие программисты пишут хорошо на любом языке (кто-то умудряется даже в эзотерические уметь), остальные предпочитают обсуждать «слабые стороны» языков, в которые они не смогли.
                                                                                                                                                                                                    Се ля ви.

                                                                                                                                                                                                      +5

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


                                                                                                                                                                                                      Правда, хорошие программисты могут писать и на ассемблере, но зачем специально вставлять им палки в колеса то?

                                                                                                                                                                                                        –1
                                                                                                                                                                                                        А мысли об ассемблере приходят в голову все чаще и чаще…
                                                                                                                                                                                                    +4
                                                                                                                                                                                                    Ну Вы, конечно, молодец, низвели тему беседы к словоблудию.
                                                                                                                                                                                                    Можно дерево «срубить» быстро и удобно бензопилой, а можно долго и усердно топором.
                                                                                                                                                                                                    Так вот если я ценю время и силы — мне нужна бензопила, если я хочу заняться известным делом, сродни библейскому Ананию, то мне пойдёт и топор, а может и ложка.
                                                                                                                                                                                                      –3
                                                                                                                                                                                                      Вашему лагерю пора бы уже определиться: то ли вы за свободу и творчество, то ли за удобные и простые инструменты.
                                                                                                                                                                                                      А то когда речь заходит о дженериках, вам подавай готовую спеку языка, предполагающую решать конкретную проблему конкретным способом, во всех остальных случаях у вас этот же подход вызывает истерику и вот такие статьи.
                                                                                                                                                                                                      П — последовательность.
                                                                                                                                                                                                  0
                                                                                                                                                                                                  Я не имею ничего против дженериков, но мне до сих пор не понятно, почему в какой-то момент времени их наличие стало критерием качества языка?

                                                                                                                                                                                                  Один из критериев "качества языка" — возможность лаконично выражать разные абстракции. Простой пример — коллекции элементов различных типов, но не стандартные, а создаваемые пользователем языка (ну, какой-нибудь R-Tree или Trie, или LinkedHashMap, если у вас нет jvm). Для этого могу вспомнить 3 подхода:
                                                                                                                                                                                                  1) Динамические языки. В коллекцию можно добавить любой тип, проверки во время компиляции нет. Просто, но наличие юнит-тестов желательно.
                                                                                                                                                                                                  2) Копипаст. Адовые заклинания на препроцессоре С, кодогенерация или ручной копипаст. Стандартного способа нет, используются нестандартные, кто во что горазд.
                                                                                                                                                                                                  3) Статические языки с generic'ами, ко- и контравариантностью типов-параметров. Позволяют описать коллекцию, наложить ограничения на типы-параметры, проверить ограничения во время компиляции. Сложно, но надёжнее и быстрее, чем динамических языках.
                                                                                                                                                                                                  Если ваш язык статически типизован, приходится выбирать между 2 и 3. Подход 2 будет похуже из-за ненаглядности исходного кода, неожиданных ошибок, отсутствие поддержки IDE. Подход 3 сложен, но основная сложность в написании компилятора языка и IDE.


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

                                                                                                                                                                                                    0
                                                                                                                                                                                                    Простой пример — коллекции элементов различных типов, но не стандартные, а создаваемые пользователем языка
                                                                                                                                                                                                    «Янепрограммист», но для решения чего-то подобного в чистом C у меня была структура из char'а, указывающего тип и union'а со всеми комбинациями элементов. Это-вот не оно? Я просто не понимаю…
                                                                                                                                                                                                    Или речь о том что типы проверять еще на этапе компиляции? Как в шаблонах С++? Но так если в массиве элементы разных типов, то такое не сработает, все-равно придется их в рантайме определять.
                                                                                                                                                                                                      +1
                                                                                                                                                                                                      Но так если в массиве элементы разных типов, то такое не сработает, все-равно придется их в рантайме определять.

                                                                                                                                                                                                      Если вы статически знаете множество допустимых типов, то можно хранить ADT с этими типами. Хранить в массиве набор непонятно чего за всю практику мне нужно было… ну, я уже не помню, когда.