Во время очередного спора знакомый озвучил мысль, которая меня очень сильно задела. «В большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом. Поэтому их код легко читаем, предсказуем и надежен. И поэтому крупный бизнес выбирает Go». Это достаточно мощный аргумент, над которым нужно как следует поразмыслить, прежде чем опровергать.
Поэтому я в два счета размазал его, прицепившись к отсутствию дженериков, а умную мысль унес, пожил с ней несколько дней, и в какой-то момент сформировал свое мрачное видение.
Моя работа — выбрать как можно более подходящее решение из бесконечного числа комбинаций. Это то, за что мне платят, и это то, за что я люблю свою работу, а потому и свою жизнь. Но мне говорят — супер решение не нужно. Нужно обычное. Потому что готовый продукт важнее его реализации.
Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом. Так компании будет намного комфортнее. Бизнес не хочет зависеть от случайностей. Мысль, что плохое настроение ведущего разраба отнимет у бизнеса кусочек прибыли, не нравится топ-менеджерам. Они стали топ-менеджерами, потому что хорошо умеют избегать ситуаций, когда их священный бизнес теряет деньги. А мы сейчас живем в то время, когда «хорошо сделанное» и «прибыльное» — разные вещи.
И я прекрасно понимаю, как мы к этому пришли. Сейчас объясню, следите за пальцами:
Я, как и большинство инженеров, верю, что творю великие вещи. Что изобретаю, автоматизирую, делаю своим трудом и мозгами жизнь всего человечества лучше, пока всякие мракобесы только мелят языком. Но потом я вытаскиваю нос из своего редактора кода, и прихожу в ужас от того, как жестоко ошибаюсь.
Что я вообще нахрен делаю?
Вот я продумываю архитектуру высоконагруженной системы, но в 95% случаев ее будут применять, чтобы быстрее отсортировать на телефоне селфики с узорами и фоточки любимой собаки. Вот я разрабатываю VPN-клиент, и что с ним будут делать? Смотреть всякую порнуху и тупые пиратские фильмы?
Мои мозги обслуживают мелкие ежеминутные хотелки, чтобы люди принесли мне деньги, чтобы я тоже удовлетворил свои хотелки.
В ИТ делают хорошие вещи, но их процент ничтожно мал. Большинство обслуживает дурацкие потребности, которых раньше просто не существовало, потому что не существовало ИТ. То есть, инженеры не делают великие вещи, инженеры просто поддерживают инфраструктуру перекачки бабла между людьми.
В таких условиях писать хороший код перестает быть необходимым. Это нужно только для того, чтобы мне было веселее работать, и я подольше не выгорал. Но рано или поздно приходит топ-менеджер и говорит: «Все, заколотите гвоздями и пуляйте. Пора стричь бабло».
Вместо абстрактного «всеобщего блага» ИТ научилось потакать низменным хотелкам и только за счет этого выросло в гигантскую индустрию, где работают сотни миллионов людей. Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.
И когда он попадет в индустрию, времени копать глубоко уже не будет — продукт нужен сегодня вечером, иначе мы упустим деньги. Копать глубоко и изучать технологии превращается в хобби, нужное только для того, чтобы не свихнуться от осознания собственной никчемности.
В системе, где надо раз в неделю выкидывать на рынок новую фичу, нужны простые подходы и примитивные инструменты. Когда какой-нибудь крутой разработчик придумывает новую технологию, он старается сделать её так, чтобы она была востребованной большинством, потому что востребованность большинством — главная ценность современного мира. Вот почему появляются такие вот философии и такие вот Go.
А я думаю — мне это всё нахрен не нужно. Это все вызывает отторжение.
Если хорошо присмотреться, мой VSCode набит опасными симптомами. Мой tslint не разрешает добавить мне лишний пробел. Мой код не билдится, если я назвал переменную не с той буквы. Мой компилятор не будет работать, потому что я не добавил комментарии к публичному методу. Тут все просто — пишите, ребята, одинаковый код. Безликий код. Это вам не роман, какой к чёрту авторский стиль?!
Я в целом согласен, что подобные конвенции — хорошая штука, но только до тех пор, пока они касаются внешнего вида кода. Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар. Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже». Звучит абсурдно? Вот так и будет. Серьёзно. Да так уже есть. Они не добавили дженерики в Go, потому что дженерики — сложные.
Go — это бизнес-эффект, а не инженерное решение. Он сам себе противоречит. Вот он хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности. Дженерики существуют именно ради надёжности, чтобы предвосхищать потенциальные баги dev-time. И да, они довольно сложны.
Программируя, я хочу заниматься творчеством. Хочу иметь огромное число опций, когда дизайню систему. Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение. Но это же обман! Пусть он и сработает, но всегда есть решение лучше. А под давлением того, что у нас нет бюджетов на качественные решения, мы сами убиваем софт, и потом разочаровываемся, что все плохо работает.
Философия безликого кода хочет сделать из меня машину, которая копипастит бойлерплейт. И думая об этом, я прихожу к еще более страшному противоречию.
Я всегда верил, что базовый посыл разработки звучит так: «Все, что может быть автоматизировано, должно быть автоматизировано». Но вот ирония — мой посыл тоже фатален.
Я не готов делать что-то, что могла бы делать машина, которую я могу построить. Это нерационально, а меня учили быть рациональным. Но раз я должен все автоматизировать, выходит должен автоматизировать и автоматизацию — то есть разработку. И получается должен быть рад языкам, которые постепенно нас к этому подводят. То есть моя профессия, как и большинство других, в идеальном мире существовать не должна.
Прогресс не остановить. Но он может идти разными путями, в этом я уверен точно. Если программирование сейчас свернет на дорожку Go и безликих практик, то мы придем к самой кривой и не оптимизированной автоматизации, какую только можно представить.
Мое решение проблемы — утопическое, и не выдержит никакой критики. Я понимаю, что его уже поздно предлагать, но все же.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Да, это затормозит прогресс на века и лишит нашу жизнь всех приятных плюшек, на которые мы ежедневно залипаем. Но по крайней мере это вернет идею прогресса к тому виду, в который мы верим в моменты наших самых сильных идеалистических порывов.
Комментарии (318)
altrus
26.12.2018 17:01+4Надо создать профессиональную ассоциацию программеров
неговнокодеров
С уставом и всё-такое
В других специальностях есть подобные институты
Будет, с одной стороны, такой знак качества, а с другой — хранители истинного духа и традиций
Как дети-индиго, только наоборотj_wayne
26.12.2018 17:19Не совсем конечно ассоциация, но есть подобное течение: en.wikipedia.org/wiki/Software_craftsmanship
JustDont
26.12.2018 19:37+1Создать можно, но не поможет. Замените в тексте статьи программиста на кузнеца, и всё будет так же. Он тут такой, красивый и в белом пальто — делает мир лучше, искусством занимается и тэ дэ, а ему тут нннннннннааа по голове непонятными штуками под названием «стандартизация» и «индустриализация». И как жить, когда кто-то станками клепает взаимозаменяемые детали тысячами, пока ты со всем своим искусством и трогательным отношением делаешь одну?
С кодом всё точно так же. И ниши для штучного программирования и искусства всё равно всегда будут, только вот все в них не влезут.AllexIn
27.12.2018 12:03+2только вот все в них не влезут.
С влезанием нет проблем.
Но в таких областях как правило меньше платят. Ровно настолько, чтобы количество желающих было лишь чуть-чуть больше спроса.
YetAnotherSlava
26.12.2018 21:39+2Вы правы. И как пример можно привести адвокатское и врачебное сообщества в США. Чужих они не пускают. Совершенно неэкономическими методами.
Angmarets
26.12.2018 22:29+2И что в этом хорошего?
YetAnotherSlava
28.12.2018 22:55Медицина в США — лучшая на планете. Как и юристы.
0xd34df00d
28.12.2018 23:07+1Нет, по крайней мере, медицина там далеко, скажем так, не самая оптимальная. И во многом за счёт непускания чужих.
Angmarets
29.12.2018 01:10+1Медицина в США — лучшая на планете
«Я тебе конечно верю, разве могут быть сомненья».
В контексте «лучшей медицины» я еще слышал про Израиль, Испанию, Британию и Канаду. Почему верить я должен именно вам?
А еще даже если вы выработаете критерий «лучшести» медицины и докажете, что она лучшая именно в США, вам также предстоит доказать, что закрытость — это именно причина топового места и медицина лучшая именно благодаря этому, а не вопреки.
Как и юристы.
Собственно все то же самое, просто замените медицину на юриспруденцию.
snuk182
27.12.2018 00:13-3Некто Robert C. Martin похожему посвятил минимум одну книгу. Получилось максимально уныло, с кучей нравоучений. К сожалению, ее иногда спрашивают ашары.
Squatch
27.12.2018 00:33+4Надо создать профессиональную ассоциацию программеров
сепия-старцы?)
Как дети-индиго, только наоборот
mOlind
26.12.2018 17:03+1У Go остается свобода в выборе паттернов, алгоритмов и имен переменных. Но многие задачи имеют простое и правильное решение. Это удобно и делает код чище и легче читаемым. Можно зайти в произвольное место стандартной библиотеки, посмотреть как и что написано, без труда понять это и использовать похожий подход. Ничего в этом плохого нет.
Если сравнить с stl от c++ это просто небо и земля. Там хоть и исходники доступны, но понять что же все-таки происходит. Надо как-то понять в каком месте какого шаблонного класса объявлен какой тип и в каком шаблоне он используется и зачем. Вместо объявления интерфейса и требования соблюдения этого интерфейса есть привязка к именам типов и методов и это так усложняет понимание кода, что надо гораздо больше времени чтоб вникнуть. Не говоря уже о том чтобы скопировать увиденный подход к себе в приложение. И вот в чем проблема когда задачу можно решить 15ю способами одна и та же проблема в разных местах приложения будет решена по-разному. Часть из этих решений будет простыми и неправильными. А это уже ведет к разному поведению и такие куски кода может быть тяжело заметить, чтобы свести к общим функциям.creker
26.12.2018 18:58+1Очень знакомо и при знакомстве с языком меня сильно удивило. Как-то привык я, что лезть в библиотеки это дело гиблое. Там всегда черт ногу сломит. Проще погуглить решение проблемы, авось кто-то сталкивался. А в Go лезть в код рантайма стало обычным делом, когда мне что-то непонятно или любопытно. Я бы и мог тоже самое сделать с помощью тестового проекта, дебаггера, гугла, стэка, но незачем. Быстрее прочитать и самому все увидеть.
potan
27.12.2018 12:27+1Когда я программировал на C, приходилось заглядывать в код ядра, что бы разобраться в пользовательском приложении.
С тех пор я перешел сначала на Haskell, потом на Scala, и что бы разобраться в библиотеке часто достаточно посмотреть ее интерфейс, даже не документацию. Я этим очень доволен.
0xd34df00d
27.12.2018 00:32+2Не далее как вчера мне потребовалось ровно 10 минут, чтобы понять, почему
std::any_castнекорректно работает в libstdc++.
potan
27.12.2018 12:15+1C++ и stl создавались в прошлом веке с целью заткнуть текущие дыры в разработке. Не удивительно, что получилось не слишком изящно.
Сравнивать надо не с ними, а с академическими Haskell и SML, и с современным, вобравшим лучшие практики Rust.mOlind
27.12.2018 14:00-1Ну это вы загнули. Мы в работе используем С++17, который достаточно свеж. :) Сама концепция определения требований у шаблонов хромает. Когда привязка идет не к интерфейсу, а по наличию методов или под-классов с нужными методами. Их нет — получишь ошибку с ссылкой на дебри шаблонной функции где сигнатура не совпала или метод попробовали вызвать. Было бы следование интерфейсам как в Go — сразу получили бы ошибку, мол класс не реализует интерфейс A, надо добавить метод B.
potan
27.12.2018 19:14Дизайн унаследован с древних времен, его уже тяжело переделать. Во многом от сюда и сложность поддержки библиотек.
vintage
27.12.2018 23:48К С++ шаблоны были прикручены сбоку, отсюда и все проблемы. Возьмите язык, где шаблоны были изначально и удивитесь как всё внезапно становится понятно: run.dlang.io/is/vjmZFx
KirEv
26.12.2018 17:12+11я программирую после работы.
gerashenko
26.12.2018 23:06+1Что программируете? Почему не можете это сделать работой?
Whuthering
27.12.2018 12:44Меня всегда искренне удивляли такие вопросы.
Во-первых, далеко не за всё, что интересно пилить какому-то человеку, другие люди готовы платить хорошие деньги, или вообще готовы платить. Все-таки группы проектов «интересно» и «выгодно» часто не пересекаются.
Во-вторых, я для себя давно уже вывел простое правило: нельзя смешивать хобби и работу. Нельзя. Ни в коем случае, ни при каких обстоятельствах.
Я вот, например, очень люблю программировать, и очень люблю ходить по горам.
Но есть одно «но». Когда я себя неважно чувствую, или когда на улице идет ливень стеной и семибальный шторм, я наврядли захочу пойти в поход, как бы я сильно не любил это дело. А если бы и пошел, то наврядли получил бы от этого удовольствие, а мог бы еще проблем со здоровьем потом огрести. Поэтому лучше посижу в тепле и поколдую над программами в своё удовольствие.
Точно так же, я очень люблю разрабатывать ПО. Решать сложные задачи, добиваться результата, делать код и архитектуру лучше. Но в один прекрасный день у меня может оказаться такое настроение, что мне не захочется программировать, а захочется пойти в поход — птички поют, солнышко светит, друзья зовут за приключениями, никакого желания сидеть в офисе или дома, смотреть в монитор и созваниваться с заказчиками, а о коде голова вообще не думает и не хочет соображать, Но… нет. Есть заказчики, есть таски, есть дедлайны, есть проблемы, требующие срочного решения — в итоге я вынужден насиловать себя в этот день работой (хотя в другой день я бы занялся этим с радостью, и даже задержался бы до глубокой ночи, ковыряя какую-нибудь интересную задачу). В итоге постепенно совершенно остываешь к любимому делу и оно начинает тебя напрягать, как раз-таки из-за его ежедневной «обязательности» из-за того что оно стало работой.Aingis
27.12.2018 14:44+1То есть вместо того, чтобы заниматься любимым делом, пусть иногда и с усилием, вы предпочитаете всегда заниматься нелюбимым делом с усилием? Я вас правильно понял? Или вы вообще не работаете?
Whuthering
27.12.2018 15:01-1Я все больше и больше прихожу к идее, что лучше заниматься в рабочее время и в обязательном порядке пусть и не слишком любимым делом (главное, чтобы к нему не было отвращения, и чтобы за него хорошо платили), чтобы не терять искреннее удовольствие от занятий по-настоящему любимыми делами добровольно в свободное время.
AleXP3
28.12.2018 12:02Это банальная старая истина: не надо смешивать хобби и работу. Весьма рискованное дело это пытаться из хобби сделать коммерческий проект. Скорее всего лишишься и хобби и работы )
Xandrmoro
26.12.2018 17:14+14Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаково плохо
Fixed.
RPG18
26.12.2018 17:17+4Я, как и большинство инженеров, верю, что творю великие вещи.
Такие штуки как docker, kubernetes не достаточно великие вещи? Восхищаются готовым продуктом(nginx, postgresql, mysql и т.д.), а не его исходным кодом.
evocatus
26.12.2018 18:59+1А вы в курсе, что пришлось сделать команде kubernetes за отсутствием дженериков?
creker
26.12.2018 19:06Расскажите. В код залез, но так сходу в таком большом проекте не найдешь что-то.
evocatus
26.12.2018 19:25+6www.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»creker
26.12.2018 20:10Забавно, именно эту часть кода я читал, когда полез туда после вашего комментария.
Как правильно сказано в комментариях к той статье, дженерики не имеют к этому никакого отношения и проблему эту решить не могут, они для разных вещей предназначены. И тем более никакого форка не было. Они сделали вполне стандартную вещь — реестр типов. Каждый тип регистрируется руками в реестре. В рантайме какие-то данные по сети сверяются с этим реестром и если тип есть, то сериализуется экземпляр, либо выкидывается ошибка, мол, такого типа в реестре нет. Дженерики, не дженерики — если типа кто-то не написал, то магическим образом он в рантайме не появится. Дженерики, будучи фичей статической типизации, эту задачу не решат. Это пример того, как в язык вкорячили некий вид динамической типизации.
Я в C# тоже что-то подобное делал для сериализация протобуферов и дженерики мне там никак не помогли. Там нужна рефлексия, которая есть и в Go. Едиevocatus
26.12.2018 21:59+14Мой основной посыл был в том, что многие ссылаются на kubernetes как на успех Go, своего рода флагманский проект, а они сами наткнулись на очень большие грабли с Go и обошли их способом, который, фактически, отрицает саму идею Go. И на самом деле это не флагманский проект Go, который должен доказывать, что Go — серьёзный язык, на котором можно делать почти всё, что угодно, а ровно наоборот: это большой провал Go, который доказывает, что неоPascal с CSP, созданный для решения сугубо внутренних проблем Google не может автоматически быть языком общего назначения. (я так резко отзываюсь, потому что бывший фанат Go)
Перефразируя известную фразу Филиппа Гринспена: "Каждая достаточно сложная программа на Go содержит узкоспециализированную, недокументированную, забагованную и тормознутую реализацию половины CommonLisp"
Рефлексию в Go не рекомендуют использовать без крайней необходимости и неспроста (при этом буквально все используют библиотеки, которые пропитаны ей как бисквит коньяком: encoding/json, gorilla/schema и пр.). Лучше уж нормальная динамическая типизация.creker
26.12.2018 22:26-10Чето у вас каша в голове. Еще раз, это не имеет отношения к языку. На шарпе, яве, го, плюсах. Это решение везде будет одинаковым примерно с разной степенью извращенности реализации. Нигде это не будет красивым. Уж в плюсах точно, где даже рефлексии нет. Это стандартный шаблон, который многими применяется. Так решили разрабы кубера и это их проблемы, а не языка.
В вас и видно, что в вас говорит бывший фанат, который обиделся на что-то. Язык общего назначения был и остался. Кубернетис так и остается отличным примером, что язык применяется и тянет на себе целую индустрию, индустрию контейнеров, т.к. буквально все проекты в ней написаны на Go.
Рефлексию не рекомендуют по другой причине, озадачились бы узнать, прежде чем заявлять что-то. Причина всегда была и есть одна — пакет рефлексий сложен в работе, имеет много подводных камней и неочевидностей, поэтому можно натворить дел. Поэтому не рекомендуют туда лезть всем подряд, а только тем, кто разбирается. Рефлексия сложна по определению. И в стандартной библиотеке он, потому что он нужен и огромное количество библиотек его применяющих лишнее доказательство, что он нужен. По этой же причине рефлексию все пытаются добавить в плюсы.evocatus
26.12.2018 22:37+3А почему рефлексия в Go есть, хотя она «сложна в работе, имеет много подводных камней и неочевидностей», а обобщённого программирования нет?
creker
26.12.2018 22:45-3Потому что рефлексия это пакет стандартной библиотеки, а обобщенное программирование это глава в спецификации языка. Одно можно просто не использовать и никак это нигде ни на ком не скажется, а другое фундаментальная фича языка, которая наводнит весь код на нем и окажет влияние на каждую строчку кода. Одно требует просто предоставления интерфейса до того, что и так есть в языке. А другое требует очень больших усилий в грамотном дизайне, рассмотрении всех ситуаций, взаимодействия со всеми остальными фичами языка. С последним как раз очень много проблем у всех предложений по дженерикам. Без одного просто невозможно решить многие задачи, а другое практически не требуется на практике (и опыт Go за все эти годы показывает, что дженерики полезны, но не необходимы), а во всех остальных случаях заменяется встроенными обобщенными типами.
Crandel
27.12.2018 00:16+7В общем всеми любимый Роб "его высочество император галактики" Пайк облажался с упрощением на этапе создания и теперь не знает, как туда это пропихнуть?
0xd34df00d
27.12.2018 00:39+2Потому что рефлексия это пакет стандартной библиотеки
Который никак не опирается на предоставляемые рантаймом средства?
А если эти средства не описаны в спеке, то грош цена такой спеке, и нужна она только для виду. Ну или правильнее было бы называть её справочником пользователя языка.
Druu
27.12.2018 07:13+2а обобщенное программирование это глава в спецификации языка.
Полиморфизм — он и в Африке полиморфизм. Если человек знает теорию типов, свойства соответствующих систем, их влияние друг на друга — на просмотр и осознание этой главы уйдет порядка нескольких минут. Ну а если он необразован — его проблема.
А другое требует очень больших усилий в грамотном дизайне, рассмотрении всех ситуаций, взаимодействия со всеми остальными фичами языка.
То есть разработчики просто поленились?
0xd34df00d
27.12.2018 00:37+1Чето у вас каша в голове. Еще раз, это не имеет отношения к языку. На шарпе, яве, го, плюсах. Это решение везде будет одинаковым примерно с разной степенью извращенности реализации. Нигде это не будет красивым.
Я ровно эту задачу в своё время решал на плюсах с темплейтами. Да, конечно, там тоже был реестр, только он был компил-тайм.
На каком-нибудь хаскеле эту задачу решать ещё более красиво и изящно можно. С ещё большими статическими гарантиями.
По этой же причине рефлексию все пытаются добавить в плюсы.
Самое ироничное, что в плюсы пытаются добавить компилтайм-рефлексию, очень хардкорно опирающуюся на компилтайм-средства метапрограммирования, от constexpr до темплейтов (есть пара конкурирующих пропозалов).
Rockbass
27.12.2018 03:18Надеюсь Geth таким же прорывом Go не считают? А то у меня от этого продукта регулярно болит на работе.
site6893
27.12.2018 11:32пользуйтесь parity и забудьтє єтого тормозного падающего монстра!
Rockbass
27.12.2018 11:48спасибо, погуглю, но спрошу на всякий случай — он работает точно с теми же протоколами и предоставляет точно те же апи, как и geth?
мне в идеале надо бы держать и развертывать пир, как приватную сеть с clique, так и подключаться к публичной.
amakhrov
27.12.2018 06:34+3Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
То, что в статье названо "реализацией дженериков", не очень похоже на них. Примеры того, где это используется (опять же, в статье), относятся к сериализации/десериализации объектов. Это чисто ран-тайм операция, дженерики ее не решают.
Без дополнительной аргументации и приведения конкретных примеров лично мне совсем неочевидно, что автор той статьи прав, говоря, что kubernetes пострадали от отсутствия дженериков и реализовали их заменитель.
Druu
27.12.2018 07:25Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
То, что в статье названо "реализацией дженериков", не очень похоже на них.Чтобы реализовать генерики, надо патчить компилятор, очевидно. Тут правильнее было сказать не "реализация генериков", а "замена генериков", то есть, при наличии генериков воротить все эти рантайм-забавы бы не пришлось, при этом код был бы более надежен (т.к. фиксировались бы конкретные типы, вместо просто RuntimeObject).
Это чисто ран-тайм операция, дженерики ее не решают.
Дженерики решают то, что после десереализации у вас получится не объект типа Hz4e, а нормальный конкретный тип, с которым вы сможете полноценно работать.
amakhrov
27.12.2018 07:31+1А можете привести пример, как подход, реализованный kubernetes, можно было бы заменить на дженерик для какого-то из имеющихся сценариев использования?
В оригинальной статье этого нет — поэтому выглядит голословно. Но возможно, все так есть, просто автор решил опустить несущественные детали?
CheatEx
27.12.2018 15:30-3А что великого в докере? Старая проблема, старое решение, посредственные реализация и UX. Просто его выкатила контора на G — вот хомяки и возбудились.
EnotovaMorda
26.12.2018 17:17+3Да, полностью согласен с автором… Всё идет именно туда. Вспоминая Фаулера с его «Программистом-фанатиком», нужно тренироваться… дома… А не на работе. И причем именно он по сути и описал ситуацию, рассмотренную автором, перейдя в стан манагеров. Им главное выкинуть в «продакшен». А какой это ценой — баги, недоработки, неэффективный расход времени. Потому и приходит выгорание. Я к чему это все. Везде важна грань. За творчество не всегда можно получить деньги, как и не всегда можно получить деньги за говно-продукт. Нельзя работать ради работы. Также нельзя работать только ради бабла. Времени на прекрасные вещи и на жизнь не останется…
questor
26.12.2018 18:21+2Правильно ли будет тогда программистам устроить не 8-часовой рабочий день, а шестичасовой? Потому что сейчас в некоторых отраслях (геймдев тот же) потогонка такая, что по 14 часов в сутки работают, а в моменты перед релизом могут и больше.
Vantela
26.12.2018 18:45+1И все равно потом пару лет после релиза допиливают игру то минимально адекватного состояния…
Crandel
27.12.2018 00:19Или на 3 рабочих дня в Google)
Denis631
27.12.2018 13:22Только его не повышали 12 лет. Работать 3 дня это не повод для подражания, ИМХО
Если вы на работе не кайфуете, пилите что-то круто и не учитесь, то тогда это плохая работа и тогда понятное дело меньше-лучше.Crandel
27.12.2018 17:00+2Если бы у меня была такая зп, что позволяет работать 3 дня в неделю и путешествовать, как этот парень — нафиг мне то повышение сдалось? Было какое-то исследование, что после определенного порога рост зарплаты перестает приносить мотивацию. Для Европы где-то на уровне 100к, штаты — 150-200к. Деньги покрывают все потребности и смысла их больше зарабатывать нет
Denis631
28.12.2018 18:52- в гугле такие зп что люди «шикуют» относительно
-
нафиг мне то повышение сдалось?
ну каждый живет как хочет. кто-то хочет уметь дом, машину. а кто-то последние деньги тратит на путешествия.
Если вы смотрели видео то он говорил, что перейдет на фулл-тайм когда нужно будет платить ипотеку или учебы детям.
он «шикует» потому что в Гугле работал. Работал бы на обычную фирму, так бы не «выпендривался» рост зарплаты перестает приносить мотивацию
Деньги покрывают все потребности и смысла их больше зарабатывать нет
у каждого свои потребности. кому-то с любимым/ой и рай в шалаше
Если он для вас пример для подржания, то ради бога. По мне так звучит как мечта бездельника, без обидCrandel
28.12.2018 19:00Если он для вас пример для подржания, то ради бога. По мне так звучит как мечта бездельника, без обид
Я не говорю, что нужно исключительно путешествовать. Я бы проводил это время с семьей. Когда ребенок растет, ты на работе теряешь очень драгоценные моменты, которые потом не повторятся. Я работаю, чтобы покрывать свои потребности, а не жить работой. И 5 дней из 7 для меня слишком большая трата времени. Надеюсь у меня будет такая же возможность сократить это время
0xd34df00d
28.12.2018 22:05По мне так звучит как мечта бездельника, без обид
Чтобы не быть бездельником, нужно делать что-то разумное и осмысленное именно на работе?
Если я в свободное время ковыряю опенсорс или абстрактный матан — это тоже бездельничание?
Denis631
29.12.2018 12:48Если я в свободное время ковыряю опенсорс или абстрактный матан — это тоже бездельничание?
Нет. Но это позволяют делать в Гугле на работе, AFAIK.
Но это не то, чем собирался заниматся Лёва (парниша из видео про жизнь Гугле) ни Crandel
JuniorIL
26.12.2018 22:15+6А что плохого в том, чтобы работать ради бабла? Я не про гнилую контору, где сидит Федя — гриб, и погоняет Ваней — солдатиком (Федя держит все знания у себя, потому что хочет бабла, Ваня делает дерьмо по той же самой причине, все совпадения случайны). Я про коллектив, где каждый делает свою часть работы за 8 часов, старается быть максимально сосредоточенным и покрыть весь код тестами, чтобы за свою работу не зафакапить, отношения хорошие, менеджеры адекватны и дают нормальные спеки. И вот каждый божий день, приходишь, работаешь и уходишь, а потом получаешь деньги в начале месяца. Да, это не стартап, но в некоторых отделах больших контор есть вполне такое здоровое отношение к жизни.
NecroRomnt
26.12.2018 17:21+4Во многом согласен с автором. Разработка программ процесс творческий. Всегда надо иметь проект, работа над которым доставляет удовольствие.
Крик душиК сожалению реальность такова, что рынок требует разработчиков, которых нет. В конечном итоге это привело к целой вселенной JavaScript для JavaScript. Этот странный язык повсюду и на клиентской стороне, и на серверной.
Потом и этого стало мало, ведь JS сложен для восприятия и M$ сделала шикарный язык TypeScript. Этот язык в глазах многих разработчиков шикарная дама в корсете, но в моих глазах это безумный шляпник в смирительной рубашке. Ни каких больше фокусов и магии.
Самое же печальное в этой ситуации, что под давлением откровенно слабых разработчиков и их потребностей из мира разработки программного обеспечения вытесняются по настоящему эффективное использование ресурсов, повсюду программы, которые жрут как не в себя. Это про чудо софт написанный на базе электрона, и жирнющие сайты, которые раздувают браузер до мемов про оперативку и хром.vintage
26.12.2018 19:58+1И ладно бы это давало ускорение разработки. Так нет же. Пишут тонны бойлерплейта, переизобретают одни и те же велосипеды на новом стеке. Меняют дизайн, ещё не закончив менять предыдущий. В результате и разработка медленная, и получающиеся приложения.
Cekory
27.12.2018 00:40+3Пишут тонны бойлерплейта, переизобретают одни и те же велосипеды на новом стеке. Меняют дизайн, ещё не закончив менять предыдущий.
Это как раз творчество, которая творят творцы.
vintage
27.12.2018 09:34Там нет ни грамма творчества, к сожалению. Это просто хаос в попытке угнаться за хайп-трейном.
Artima
27.12.2018 17:37+1под давлением откровенно слабых разработчиков и их потребностей
вытесняются по настоящему эффективное использование ресурсовВсегда было интересно, почему эти две истории должны противопоставляться? Что мешает сделать эффективное использование ресурсов для откровенно слабых разработчиков?
junari
26.12.2018 17:21+5Что-то повеяло какой-то утопией. Бизнес нанимает разработчиков, чтобы зарабатывать деньги, а не двигать прогресс вперед. Прогресс вперед двигает наука, но и она на службе у бизнеса. Вот когда в основе человеческого общества будет лежать, например, стремление к всестороннему развитию человека, а не к беспорядочному заработку и трате бабла, вот тогда и можно ждать изменений. Корни в этом. А от осинки не родятся апельсинки.
burfee
27.12.2018 18:05Думаю и в общем-то наблюдаю, что если профессионал вложится в творчество, то за это и денег отдают. Возможно проблема в том, что все привыкли просто работать на дядю, а дядя и рад. Сейчас мало быть просто специалистом, если хочется творчества.
IgorKh
26.12.2018 17:23+3Я бы разделил бизнес и ИТ
Так а в чем проблема? Вы выбрали бизнес и сами же об этом ноете?
Собеседуйтесь в исследовательские отделения Google, IBM, Apple, Intel,…
Да даже не в ИТ: медицина, погода, ракетостроение, астрономия, прикладная физика/химия. Там у вас будет творческого программирования сколько влезет и приоритеты на качество и оптимизацию, а не выкатить побыстрее.albik
26.12.2018 20:31В этом занятный парадокс программистов: с одной стороны все такие за творчество-за творчество, которому мешают злобные капиталисты своими глупыми распорядками, лишь бы только сляпать продукт для продажи, фуфуфу, как это низко, а как же полет мысли, а с другой — раз в месяц зарплату вынь да положь.
И возникает резонный вопрос — так ты за творчество или за бабки? Если за творчество — пожалуйста, есть множество open-source проектов, где пригодится творческий порыв. Если за бабки — делай, за что платят и не выступай. Множество же айтишников хотят усидеть на двух стульях: чтобы они, понимаешь, творили, а им за их творчество, соответственно, платили. Это еще можно понять в детском саду, но когда такое на полном серьезе излагают люди 30+, то возникают резонные сомнения в адекватности человека.aeeneas
26.12.2018 21:08И при этом большинство open source проектов без корпоративной поддержки — продукты из разряда «понять и простить», несмотря на творческий порыв и высокий полёт мысли.
fukkit
27.12.2018 10:43+1Инфантилизм — чума 21 века.
Позволить себе творчество могут только свободные (от проблем удовлетворения бытовых потребностей) люди, коих всегда считанное меньшинство.
Остальные, может, и стремятся к тому, да весьма ограничены в свободе выбора.
Высокооплачеваемый раб(отник) — всё еще раб(отник), потому что жить и творить в свое удовольствие по объективным причинам не может.
Строго говоря, в корне сидит причина не совсем объективная, а точнее «совсем не» — это экзистенциальная неудовлетворенность вследствие несоответствия потребностей возможностям, мелких психотравм, незакрытого гештальта и общей недозрелости личности (привет, инфантилизм из из первого абзаца).
NeoPhix
27.12.2018 13:22+4По моему опыту «творчество» и «бизнес» противопоставляют не самые лучшие разрабы, у которых «творчество» — это одно из двух:
— бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
— бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова
Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.
А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.0xd34df00d
27.12.2018 18:27Нужно понимать, что реальное полезное творчество не может не приносить денег.
Только реальное творчество не обязано быть сиюминутно полезным.
AleXP3
28.12.2018 12:13Навеивает параллели в разного рода «непризнанными художниками», поэтами и прочими гуманитариями. И денег хочется, и на заказ работать нет желания.
yarric
26.12.2018 21:14+1медицина, погода, ракетостроение, астрономия, прикладная физика/химия
Без знаний в предметной области чистый программист там будет работать в лучшем случае в статусе code monkey: «закодь-ка мне эту формулу, чтобы строился вот такой график вот этим цветом».
Crafter2012
27.12.2018 01:07+3У возможно, это будет самое полезное, что сделает программист в своей рабочей жизни =D
arvitaly
27.12.2018 04:01Так ведь программист вне контекста предметной области — это разве что «тыжпрограммист». Что вообще общего у одного программиста и другого? Работа с логическими устройствами. А какого рода работа? Вполне конкретная — перевод команд с человеческого языка на язык логики устройства. Можно ли работать профессиональным переводчиком с английского на китайский, не зная оба языка, культуру и особенности?
Whuthering
27.12.2018 12:53+1Либо «сделай, пожалуйста, чтобы вот по этим формулам результат считался не два дня, а хотя бы за несколько часов». И дальше начинается уже интересная и непростая задача, которая не по силам code monkey, зато позволяет раскрыть в себе всё мастерство разработчика и безо всякого глубокого влезания в предметную область.
TheKnight
27.12.2018 13:51Забавно. Первая моя задача, которую я сделал в рамках полезного программирования — как раз ускорить имеющийся скрипт для расчета.
Но там пришлось как раз проанализировать данные, методы и область и предложить решение с учетом этого анализа.
worldmind
26.12.2018 17:32+1Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов.
Я примерно так отвечал когда люди говорили что хаскел сложный — сложность инструмента должна соответствовать сложности задач, как у Стаффорда Бира — сложность системы управления должна соответствовать сложности объекта управления.
Был один «простой» язык — PHP, да вот оказалось что он годиться только для простых задач, а когда его начали применять в чуть более сложных, он превратился в джаву и потерял смысл.s-kozlov
27.12.2018 06:44+1Я примерно так отвечал когда люди говорили что хаскел сложный — сложность инструмента должна соответствовать сложности задач
Поддержу, но надо помнить, что это работает в обе стороны: странно не только делать высоконагруженные отказоустойчивые сложные системы на условном JS, но и тащить условных Haskel туда, где можно обойтись JS.worldmind
27.12.2018 09:53Вот не факт — если ты уже освоил полноценный инструмент, то зачем использовать убогий?
Если ты уже умеешь гит, разве станешь юзать cvs в том проекте где его достаточно?SirEdvin
27.12.2018 10:00Я думаю тут играет эффект еще то, что на js что-то простенькое проще написать.
Это как писать телеграм ботов на go — то, что делается за неделю, программист на питоне делает за день, просто в силу того, что питон выразительнее. А производительность тут не особо играет роль.worldmind
27.12.2018 10:08+2Да, допускаю, что для каких-то прототипов, скриптов, питон может остаться, в принципе я выделяю три языковых ниши: системное программирование (Rust), прикладное с упором на надёжность/производительность (Haskell) и прикладное с упором на скорость разработки/сопровождаемость (Python).
Понятно, что любые категории это упрощение, но мне сейчас видится так. Хотя, если условный хаскел попадёт в образование и станет мэйнстримом, а значит привычным для большиснтва разработчиков, то может оказаться, что ниша условного питона очень мала.SirEdvin
27.12.2018 11:00Я довольно мало знаю о хаскелле, так что мне тут нечего сказать, но основная фишка питона в плане написания чего-то не очень нагруженного связана с тем, что на нем вы пишите исключительно логику, избегая всяких связываний и бойлерплейтов.
То есть вплоть до того, что когда вам нужно написать какую-то консольную тулзу, вы просто пишите питоновскую функцию, добавляете библиотеку и она сама автоматически превращается в консольную команду.worldmind
27.12.2018 11:07+1Ну я тоже хаскел только немного изучал, но он тоже весьма выразительный и довольно хорошо сам выводит типы, просто во многих случаях подход другой, надо привыкать, поэтому трудно сравнивать.
Kirtis
26.12.2018 17:36+3По поводу творчества
В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов. Ничего не поменяется. Лично я не считаю, что это плохо. Конечно, растёт доля некачественных продуктов, но и количество хорошего ПО увеличивается. Можно сравнить эту ситуацию с элитарной и массовой культурой, плюсы и минусы есть и там, и там. Каждый решает сам, что ему ближе.
По поводу "элитарного клуба" программистов
И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока
Ваша цель – это сложность ради сложности. Чем сложнее процесс написания и чтения кода – тем лучше. Единственный смысл такого занятия – тешить своё самолюбие.
Также сразу встаёт вопрос, на что вы будете, например, жить, ведь ничего полезного для обычных людей вы делать не собираетесь. А значит и денег это занятие приносить не будет. На одном же энтузиазме далеко не уедешь.
StriganovSergey
26.12.2018 19:19+1[шутуа]
Представим себе своего рода Шаолинь: монастырь программистов — монахов. Живут на подаяния, оттачивая искусство программирования.
Ездят с лекциями. Дают платные уроки программирования.
И даже можно придумать им сверхзадачу.
Например они — последняя надежда человечества перед лицом опасности прявления злобного ИИ.
Они должны суметь с ним совладать во время великой битвы интеллектов :)sk1project
26.12.2018 20:03Уже есть! Опенсурс же :)
Живут на подаяния, оттачивая искусство программирования.
Именно так и живет опенсурс
Ездят с лекциями...
Очень любят потусить на конфах!
И даже можно придумать им сверхзадачу.
Тоже есть — борьба с проприетарщиной, в частности виндовс-капец
Vilaine
26.12.2018 20:47В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов
Только вот книги или фильмы почти всегда — самоцель, конечный продукт. А код является самоцелью только в книжках Кнута. Но в иных случаях он всегда вторичен по отношению к задаче. Никому он неинтересен в отрыве от неё. То есть логически не получается (по крайней мере в том же ракурсе)
Каждый решает сам, что ему ближе.
То есть если в кино абстрактная красота может иметь ценность без обоснования, то в коде только в контексте решаемой задачи (как это лучше поможет её решить).s-kozlov
27.12.2018 06:46А код является самоцелью только в книжках Кнута.
… и в статьях автора сабжа.
Zarathu5trA
26.12.2018 20:49А вот тут интересная заковыка получается. Если отойти немного от темы и оглянуться вокруг, то мы увидим философию с диалектикой Гегеля и синергетику, которые пытаются понять как развиваются системы. И вот они как раз почему то констатируют что все развивается от простого сложному. Просто есть условно говоря «плохая» сложность, которая всем мешает, и «хорошая» сложность, которая служит фунадентом, для построения систем нового порядка. Переход от вычислений на бумаге и счетах к компьютерам тоже ж по своей сути был увеличением сложности, но… на нем выросли целые отрасли, поменялись экономические модели и социальные отношения. Все стало проще? Отнюдь. Увеличение сложности еще не значит что это плохо.
fivehouse
26.12.2018 17:40Автор естественно хочет себя реализовать. Хочет оставить какой-то след, который будет жить самостоятельной жизнью и иметь черты автора, что понятно. Это важная потребность человека. Корпоративное программирование это совсем не то место, где это случается. Хотя по началу кажется, что это именно то самое место. А нет. Если автор хочет себя реализовать в программировании, он должен делать что-типа Skype-а, каким он был во время своего появления; какое-то уникальное очень полезное ПО. И скорее всего свое.
Часто девиз бизнеса — безобразно, но единообразно. Но основное противоречие в том, что автор пытается реализовать себя в «работе на дядю». Дядя лучше знает, что ему нужно. И готов подавлять позывы рабочих к самореализации требованиями и деньгами. Дядя реализовывает себя.
Но кое-что может остаться кроме денег. Это квалификация, которую могут оценить другие и которая может открыть новые возможности. Если же и этого не остается, то из такого места надо точно бежать, если там не платят 100тысячмиллионов, использую которые можно себя реализовать или потом или в свои проектах.
Vantela
26.12.2018 17:45+1Да, да и еще раз да.
Пришел к подобным выводам 7 лет назад и ушел в сисадмины. Сисадмин может себе позволить программировать для себя.
Так что теперь программирование это или скрипты для работы или хобби. Вот сейчас решил джаву вспомнить.
PS Ну, ладно. И за большими деньгами ушел. Тоже. ;-)
jevius
26.12.2018 19:13+2От созидания в эксплуатацию?)
И где это у админов большие деньги? В среднем меньше чем у кодеров
Vantela
26.12.2018 19:25У САПеров больше. И в среднем и в частном.
В том то и дело. Текущее программирование уже как бы и не созидание.
Как бы кратко сформулировать то.
Есть правила как назвать переменные, как назвать функции. Как построить работу модуля\программы\чего угодно. Есть правила для внешних интерфейсов для внутренних. Правила для всего. Делать какое то изящно-красивое решение — нельзя. Мало того что оно как правило больше времени займет, так и не поймет потом никто. Поэтому только самое простое, только в лоб.
Если вы пишете проект командой, то код который вы должны написать, он как бы уже виртуально написан. Просто вы его должны напечатать.
И самое ужасное — я отлично понимаю, что так и должно быть. Что все эти правила обеспечивают и понимание другими людьми моего кода, и мое понимание чужого, и я через год благодаря этим правилам пойму что сам же написал. И меньше ошибок будет и прочее прочее.
Кратко не получилось.jevius
29.12.2018 10:35Тяжело не согласиться. Но это так только в прикладном программировании, а оно не одно в индустрии.
Про "виртуально" написанный код. Ну так виртуально много чего существует, просто мы еще этого не знаем. Почему и корректен именно термин "открытие" в науке. Все примеры решены, гипотезы доказаны. Это весь мир так устроен
kasthack_phoenix
26.12.2018 17:51+5Это вам не роман, какой к чёрту авторский стиль?!
Именно. Программист — инженер, а не писатель, вы реализуете спецификацию. Ваш код должен быть безликим, чтобы человек, который будет работать с вами просто вносил необходимые изменения, не тратя время на осознание вашего 'авторского стиля'.
Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар. Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже».
Напомню, что код пишется для людей. Если кроме вас его никто не может понять, то бизнес зависит от того, как успешно вы уворачиваетесь от автобусов. Завтра вы написали заявление по собственному — код можно выкидывать.
Впрочем, вы сами написали это ниже:
возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом. Так компании будет намного комфортнее
Не можете написать просто и эффективно — страдайте.
Они не добавили дженерики в Go, потому что дженерики — сложные.
- В Go 2 дженерики будут
- Те, кто хотел, использовали кодогенраторы.
- Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.
- C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
EnotovaMorda
26.12.2018 18:07+1Я так понял автора, что он делал упор не на то, что код должен быть витиеватым, а на том, что оптимальность и стиль конечного продукта неважен в современном бабломире.
Я лично за единую архитектуру проектов в рамках конкретного бизнес-решения (мне нравится DDD).
maxzh83
26.12.2018 18:12Именно. Программист — инженер, а не писатель
Мне ближе метафора «строитель», она нагляднее.
fillpackart Автор
26.12.2018 18:29+5В Go 2 дженерики будут
Вот когда будут, тогда и поговорим.creker
26.12.2018 18:33-1И вероятность их появления все еще небольшая. Дженерики все еще слишком сложные и их ценность это не оправдывает.
SirEdvin
27.12.2018 20:52+1Подскажите, а сложные для кого?
Для программистов? Мне кажется, концепция программирования с каналами и горутинами, которая используется в go куда сложнее, чем "ой, мы можем параметризировать типы".
Для разработчиков языка? Очень грустно, учитывая, что все остальные языки довольно легко это освоили.
SirEdvin
26.12.2018 20:41Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.
А вы точно знаете, что такое дженерики и зачем они нужны? И как бы, зачем вы требуете их в питоне?
Ну и алсо, в питоне есть дженерики, как только там ввели подсказки по типам.
C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
И сколько из-за этого боли испытывают java программисты, вы не представляете. И даже есть очень долгоиграющий проект, который пытается это пофиксить, но все никак.
kasthack_phoenix
26.12.2018 23:04А вы точно знаете, что такое дженерики и зачем они нужны?
Я пишу на шарпе и не пишу на Go.
Ну и алсо, в питоне есть дженерики, как только там ввели подсказки по типам.
Они не энфорсятся интерпретатором — их по сути(т.е. они даже видны в рантайме, чем пользуются некоторые DI-фреймворки, но это скорее сайд-эффект) нет, если не учитывать сторонние линтеры.
И как бы, зачем вы требуете их в питоне?
Их и не может быть в питоне в чистом виде — нет нормальных типов => нет дженериков. На питоне делают руками то, что реализует компилятор и рантайм в том же C# и добиваются успеха, выдавая сложный и рабочий код — точно так же смогут и в Go.
Собственно, по этой причине я не согласен с автором.
Неизмеримое количество нетривиального и полезного софта написано вообще на сях, без дженериков(да, есть макросы, но всё же), вывода типов, исключений, чего угодно — посредственные разработчики просто бы просто не вытянули такие проекты. Опенсорсного, кстати — это не какой-то большой дядька решил, что они сэкономят бюджет, а выбрали сами девелоперы.
На F# же, который автор поставил в теги и, скорее всего, считает хорошим языком, я слышал только о FAKE, который не то, чтобы сильно популярен или не имел аналогов.
Где все те гениальные проекты, которым мешает простота языка и грязные решения? А нет их, не подтверждает реальность слова автора.
SirEdvin
27.12.2018 09:46Их и не может быть в питоне в чистом виде — нет нормальных типов => нет дженериков. На питоне делают руками то, что реализует компилятор и рантайм в том же C# и добиваются успеха, выдавая сложный и рабочий код — точно так же смогут и в Go.
Эм… что? То есть помимо того, что нормальные типы то у нас есть, у нас строгая типизация, все-таки, в питоне вы не делаете это ручками. У вас просто нет типа у переменной (потому что типизация динамическая), а следовательно нет нужны в дженериках, потому что у вас все работает как-будто под дженериками.
Грубо говоря, если на C# без дженериков вы бы писали как-то так (псевдокод):
Array x = new Array(); int a = 5; x.add(a); assert a == castToInt(x[0])
То в питоне приведение типов вам не нужно, потому что при добавлении в список тип переменной не затирается.
kasthack_phoenix
27.12.2018 13:04Эм… что?
То есть помимо того, что нормальные типы то у нас есть, у нас строгая типизация, все-таки
в питоне вы не делаете это ручками.Вы делаете:
- Обеспечиваете типобезопасность.
- Реализуете менее очевидные вещи, которые достаются с дженериками. В 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();
Т.е имея информацию о типе для дженерика создавать инстансы объектов. Всё это можно сделать в питоне, но придётся в явном виде передавать типы и интерпретатор даже не ругнётся, если где-то типы окажутся несовместимы / код упадёт где-то дальше.
SirEdvin
27.12.2018 14:35Почти все, что вы написали в целом относится к вопросу «динамическая или статическая типизация» на мой взгляд.
Ну, исключая тот факт, что в питоне вам не нужно передавать тип, вы можете просто достать тип из объекта.
sshikov
27.12.2018 20:32>В java так нельзя из-за type erasure
Вообще-то можно. Типы полностью никуда не исчезают, они всегда в рантайме были, хотя не везде, да и достать их не всегда просто. Гуглите например guava typetoken.
Denis631
27.12.2018 13:24C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?
Проблема (была?) с дженериками в Go в том, что дизайнеры говорят, что это зло, а не то, что: «ребята, блин, неуспели, скоро допилим, ждите»
Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода
Карл, зачем в динамических языках дженерики?kasthack_phoenix
27.12.2018 14:01С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?
Я не говорю, что это повод для подражания. Я утверждаю, что отсутствие дженериков(и любых других фич языка) только усложняет работу, заставляя писать больше кода, но точно не стирает границу между сильными разработчиками и слабыми, как утверждает автор.
Sabubu
26.12.2018 18:06+5Не понимаю, что плохого в простом коде? Простота — это красота. Программа должна быть логичной, как «Начала» Евклида. Не испытываю симпатии к «сумрачным гениям», которые вместо того, чтобы сделать нормально, начинают изобретать какие-то только им понятные подходы.
fogone
28.12.2018 12:19+1Простота — это красота.
Это абсолютно верно. Проблема начинается, когда упрощение работает против выразительности и безопасности. К тому же язык программирования чем-то схож с языком естественным, на нем тоже человек выражает какие-то свои мысли. И если тебе всё время нужно говорить про «снег», то хотя бы одно слово для этого нужно вместо «то, что холодное, белое и падает с неба». Это я к тому, что упрощение хорошо только до некоторого предела, гоу на мой взгляд эту грань перешел.
maxzh83
26.12.2018 18:10+1Проблема известная — ремесло vs творчество. В ремесле как правило деньги, в творчестве как правило свобода. Сочетание денег и свободы можно поискать в стартапе, но обычно такое длится не более полугода. Дальше либо начинается ремесло, либо инвестор перестает спонсировать «творцов».
dimkss
26.12.2018 18:15>> Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока.
GitHub / open source, или это не то?
dzsysop
26.12.2018 18:16+1Не могу согласиться с автором по нескольким причинам.
Во-первых неправильные вводные:
в гигантскую индустрию, где работают сотни миллионов людей.
Возможно автор забыл что на земле всего 7.5 млрд человек. Из них примерно 50% нетрудоспособное население. Остается всего давайте скажем 3.5 млрд. «сотни миллионов» предполагают хотя бы «2 сотни млн». То есть Двести Миллионов программистов. Вы уж извините, но мои оценки намного скромее, дай бог если на планете есть 10 млн ИТшников.
Но мне говорят — супер решение не нужно. Нужно обычное.
Примерно такая же попытка обобщать на некотором количества личного опыта. В программировании, как и в практически любой отрасли, есть «гении» и рабочие пчелы. Да пчел больше. Но никто не отменял и не мешает автору или любому из нас стать «гением». Именно они меняют индустрию год за годом. Именно они пишут новые языки программирования и изобретают новые концепты. И уже рабочие пчелы либо принимают предложенныеконцепты либо отвергают их.
Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом.
Это относится далеко не ко всем «пчелам» и совсем не относится к «гениям».
А мы сейчас живем в то время, когда «хорошо сделанное» и «прибыльное» — разные вещи.
Это не новое время. Так было всегда. Сделать мало — надо еще донести продукт до потребителя, обосновать справедливость цены, продемонстрировать удобство для пользователя, доказать что «хорошо сделано» и в общем случае что цега-качество как минимум не хуже чем у конкуренттов. Все это основы торговли и экономики и так было всегда с момента изобретения денег и появления хоть какой-либо альтернативы и конкуренции.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Это уже как я сказал сделано, просто не так радикально. Когда гиганты индустрии работают над новыми чипами, языками, системами, протоколами, они не ограничены только потребностями бизнеса, они делают что-то просто потому что они верят что это хороший продукт. Да иногда они бросают какие-то не «выгоревшие» продукты и проекты.
Но если вы имеете в виду радикально не разрешать бизнесу программировать. Это нео-цифровой-тоталитаризм? Вы хотите продавать или давать свой код бесплатно только тем кто «заслужил»? и только в «квадратной» упаковке? вы серьезно? У меня теряется дар речи от такого предложения.
Я понимаю что у вас лично что-то там наболело. И у вас возникли какие-то мысли по какому-то поводу. Но ни вводные данные не вызывают особого доверия и не выдерживают критики. Ни ваши выводы не вызывают во мне ни симпатии ни поддержки. В некоторых предложениях я вижу нить рассуждений, но это проблески здравого смысла, которые никак не связываются ни с вводными данными ни с выводами, которые вы делаете.
Моя позиция состоит в том, что есть области где любые нестандартные и творческие решения очень даже приветствуются. Если вам надоело быть «машиной» для программирования, просто поищите другие проекты — их много. Достаточно много.
Просто вы можете обнаружить что там уже довольно высокий порог входа. Что все о чем вы «мечтали» уже есть.
Или начните свой проект. Напишите свой язык программирования. Не забывайте что Linux был создан студентом. А PHP был по сути полускриптом для личного пользования. У вас есть что-то что отражает ваши «творческие» порывы в программировании? просто доведите это до какого-то состояния и положите на гитхаб. Вы очень удивитесь насколько это может оказаться интересным окружающим.
Я не согласен с Вами и Вашими выводами. На мой взгляд, индустрия делает отсев ненужного в автоматическом режиме и делает это хорошо. Места для творчества много просто не надо искать его в поддержке сайтов на WordPress или в пресловутом 1С. Если ваш последний опыт не очень вас удовлетворяет — не делайте выводов об индустрии и бизнесе. Просто сформулируйте что именно вам хотелось бы делать и ищите подходящий проект, поверьте выбор огромен и возможно где-то сейчас ищут именно Вас!
Akon32
26.12.2018 18:19+3Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.
Например, проблему отсутствия generic'ов — одинаковым копипастом. Хотя постойте, некоторые (судя по комменту выше) используют кодогенераторы.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.
Каким образом будет финансироваться программирование ради программирования?
Программируя, я хочу заниматься творчеством. Хочу иметь огромное число опций, когда дизайню систему. Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение.
Имхо, творчество заключается не в расстановке пробелов, а в создаваемых фичах. Для творчества всё равно остаётся огромное пространство — какие фичи реализовать и как.
Вместе с моделированием реальности программные системы моделируют и сущности, не имеющие к реальности отношения — примеры есть среди паттернов программирования. От творчества, от выбора способа, каким образом реализовать фичу, по-прежнему не уйти.
А пробелы и табы — это не так важно, как фичи.creker
26.12.2018 18:30Например, проблему отсутствия generic'ов — одинаковым копипастом.
А для многих других проблемы такой нет и вовсе. go generate так вообще ниразу не трогал. В это людям обычно сложно поверить, особенно живущих только в мире сложных и больших языков, но встроенных дженерик массивов и словарей достаточно практически для всего. Я дженерики конечно жду в Go 2, но мне лично все равно, будут ли они или нет. Есть куда более важные вещи, которые стоит сделать в новой версии. И если дженерики надо принести в жертву ради этого, то будут только за. Потому как Go 2 хоть и делают, но раздувать спецификацию до размеров плюсов никто не собирается. Будет добавлена пара тройках больших фич.
creker
26.12.2018 18:25+6И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение. Но это же обман!
Смысл того, зачем Go отрезал от себя намеренно как больше частей, это получить небольшое число фич, но которые идеально совмещаются и все ортогональны друг другу. Нет ничего хуже, чем новая фича в языке, которую надо гвоздями прибивать к другим конструкциям, потому что кто-то не думал обо всех вариантах ее приминения. Это имеет далеко идущие последствия, когда библиотеки находятся в постоянном подвешенном состоянии и экосистема так и не сходится на чем-то одном. За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.
В конечном итоге, Go это всего лишь язык. Никого он ничем не ограничивает там, где это действительно имеет значение. Он позволяет написать абсолютно все что угодно бесчисленным числом способов.
Go — это бизнес-эффект, а не инженерное решение
Как раз таки это инженерное решение от и до. Его придумали инженеры для инженеров и они же его выбирают. Не бизнес нахайпил Go до сегодняшнего уровня, а программисты, которые на выходных побаловались и агитировали остальных перелезть на него. Таких историй туча и всегда инициатива исходит от инженеров.
Вот я программист, бизнес мне нафиг не сдался, я код пишу и творю. Мне не нужен язык с десятком вариантов сделать одно и тоже. Это пройденный для меня этап становления как программиста. Go один из немногих языков, который приносит удовольствие. Я писал и продолжаю писать на разных языках, но он вот такой единственный. И при любой возможности я пытаюсь писать новый проект именно на нем. Я не только удовольствие получаю, так я еще заодно получаю все преимущества его экосистемы. Я ничем не жертвую даже.
Продолжать можно долго, но почти во всем у вас наблюдается явное непонимание зачем это все сделано. Весь пост пропитан какой-то джуниорской наивностью. Иначе вас бы не удивляло требование переписать слишком сложный сервис, пусть чуть медленнее. Это очевидная вещь.nsinreal
27.12.2018 00:31+2За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.
А можно примеры? Ну кроме стандартной проблемы вызова асинхронного кода из синхронного. А то как-то ни разу в моей практике реальных проблем не было.KostaArnorsky
27.12.2018 04:29+1Тоже в недоумении, пожалуй только обработка эксепшенов при вызове Wait() из синхронного кода немного корявая. Ну и к continuation нельзя невежд подпускать, обернуть все в библиотечные вызовы и пусть пишут простые async/await.
dae-fromru
26.12.2018 18:37+2Ищите позиции исследователя (research engineer), и у вас будет определённая свобода. Говорю по собственному опыту.
А так все верно, и про творчество, и про безликость.
dedalqq
26.12.2018 18:40Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.
Мне кажется, то что вы предлагаете, хорошо находит свое отражение в OpenSource. В котором бизнес не ставит ограничения по срокам. В тоже время, в OpenSource, для того, что бы оставаться конкурентоспособным стремятся решить проблему, в первую очередь качественно а не быстро.creker
26.12.2018 18:50в первую очередь качественно а не быстро.
Большое заблуждение и обобщение. Возьмем gitlab. Во многом образец open source продукта, только вот его приоритеты это набивание продукта фичами, а не исправление проблем. И исправлению ситуации не способствует даже то, что у них полно клиентов, которые им платят деньги и жалуются на проблемы постоянно.
Напротив, ненавистный golang именно по такой модели и разрабатывается. Очень осторожная разработка с предельным вниманием к качеству кода и большими сроками стабилизации продукта до того, как будет выпущена новая версия. 3 месяца разработки, 3 месяца тестирования и исправления проблем, релиз. Только вот автор там тоже будет не кстати. Там никому не нужно творчество и фантазия ради творчества и фантазии. Нужны простые и эффективные решения. А сложное, даже если оно быстро и полезно, порой и не примут. Такое уже было неоднократно. Недавно вон хотели более хитрый алгоритм сортировки добавить, но большая сложность кода стала препятствием. Не оправдывал прирост в скорости такую сложность.dedalqq
26.12.2018 19:13Да, согласен. Но так продукт бездумно набивается «от души». Ведь куда приятнее запилить что то новое а не фиксить баги =) А большое количество клиентов так как они почти монополисты на этом ранке. Ну и потом… не смотря на то, что я не владею большой информации по развитию этого проекта, смею предположить что большое количество клиентов приводит к появлению так называемых «спонсоров» которые «спонсируют» не сам проект а определенные фичи, которые там в большом количестве появляются. А это, в свою очередь, как раз таки и сваливает проект от теплого и лампового open source в сторону ужасного и требовательного бизнеса. В этом плане golang наверное ближе к идеологии opne source чем gitlab. Имхо.
creker
26.12.2018 19:29Это тоже. Жалоб среди пользователей бесплатной версии, что все больше внимания уделяется фичам, которые попадают только в платную версию, тоже достаточно. К тому же, если раньше было две версии, платная и бесплатная, то теперь там несколько уровней платности и логика, по которой фичи отбираются в тот или иной уровень, порой непонятна совершенно. Оправдание всегда одно, мол, фичи в платную версию идут те, которые для небольших команд ненужны. А если команда большая, то платите. Явно ноги растут из клиента, который попросил фичу, которая и была бы полезна небольшим командам, но некрасиво будет раздавать ее бесплатно. Так то gitlab конечно крут, конкурентов у него наверное действительно нет в плане бесплатных решений, но такая ситуация меня печалит.
Особенно проблемы с недоделкой фич. Многие вещи бросают на пол пути и в итоге оказывается, что, например, новый замечательный репозиторий контейнеров не чистит за собой и забивает людям диски терабайтами мусора. В планах было это сделать к 11.6, которая вышла на днях. План сорвался, т.к. и так туча фич запланировали. Сдвинули к 11.7. А появилась эта фича в 8.8, полтора года назад. Когда они это реально исправят черт его знает, а ведь это очень большая проблема.
andreyverbin
26.12.2018 18:42Заниматься творчеством делая очередную систему учёта невозможно, если только вы не придумали новый подход к учету. Придумать его тяжело, потому что миллион людей уже об этом думали. А раз так, то делая учетную систему вы выполняете функции ремесленника, а не творца. Язык программирования тут ни при чем, просто посмотрите на другие задачи.
Проблема с «другими» задачами в том, что прочитав книгу “Go за 21 день» их не решить. Надо много знать за пределами программирования. Например, знать какой-то бизнес, или разбираться в математике и решать с помощью своих знаний задачи. Знание Go и очередного мега фреймворка никаких задач не решает и если это все, что вы знаете, то бизнес поставит вас решать типовые задачи, не требующие творчества и спец. знаний.
Whiteha
26.12.2018 18:48+1Честно говоря я не понимаю откуда такое одобрение у этого поста.
Начиная с сорри мини-выпиндрежа про «следите за пальцами», ханжеских рассуждений про порнуху через впн и пиратство, заканчивая «Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации» — wtf, это не идеализм, это банальное не понимание реальности. В реальности ты волен выбирать работать тебе на бизнес за деньги, или сосать лапу в опенсорсе, или комбинировать так, чтобы максимально удоволетворять свои потребности. Да даже не понятно что тут обсуждать и как это толком связано с названием «Безликий код убьет программирование, и ничего мы с этим не сделаем».
ЗЫ Кто-то должен был это написать — заметка ни о чем.s-kozlov
27.12.2018 06:57ханжеских рассуждений про порнуху через впн и пиратство
Оффтоп, но достали уже употребления слов без понимания их значения.
Есть пруфы, что автор смотрит порнуху через VPN или пиратит? Нет? Тогда где тут ханжество?
AlexJameson
27.12.2018 16:28+1Точно не путаете ханжество и лицемерие?
s-kozlov
27.12.2018 19:08Это практически синонимы. Только ханжеством почему-то часто называют просто осуждение поступков, которые называющим кажутся приемлемыми. Это как если бы серийный убийца называл ханжеством осуждение убийства.
AlexJameson
28.12.2018 12:25Не совсем понял. Мне из определения ханжества нравится строчка про «Крайность в осуждении аморальности». По-моему, она тут прямо на лицо, в демонстративной форме. Не знаю как там у других, но просмотр таких вещей, а также обход абсурдных блокировок в стиле DMCA просто отличным применением VPN, наравне со многими другими вещами.
s-kozlov
28.12.2018 13:24А мне не нравится это строчка, хотя бы потому, что лицемерие объективно, а «крайность» субъективна.
Tanner
26.12.2018 18:49+1Искусство нуждается в самоограничении. Хорошие композиторы не жалуются, что нот всего 7. Архитекторы как фигачили всё одинаковыми прямоугольными кирпичами со времён Римской империи, так и до сих пор фигачат. В балете как минимум с XVI века одни и те же характеры и па. Абстракционисты все умели в пропорции и композицию, так же, как до них импрессионисты ? в цвета.
Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.TheKnight
27.12.2018 01:12Я бы сказал бы, что нот таки больше семи.
В хроматическом звукорядке, который используется в современной музыке, рассматривают 9 октав, каждая из которых состоит из 12 нот.
Семь нот — это лишь способ записи музыкального произведения, к которому добавляются знаки альтерации и ключи у нотного стана.
nsinreal
27.12.2018 22:30А бит имеет аж два состояния — вот уж простор для творца. Но почему от машинных кодов отказались
StriganovSergey
26.12.2018 19:00+2Пусть все решит естественый отбор.
Пусть клмпании, желающие «урвать кусок прямо сейчас» его получат, и с ним в зубах сдохнут. Не мешайте им убивать себя.
А сами пока пилите свои проекты по всем правилам.
Проект жив только в руках Мастера.
В руках «эффективного менеджера» он умирает.
evocatus
26.12.2018 19:06Какой бизнес, такое и IT. Иметь программу более надёжную, чем сам бизнес, бессмысленно. Это будет ситуация «без штанов и в шляпе».
90% компаний закрывается в течение первого года, 3% продолжает существовать более 3 лет.
KSA
26.12.2018 19:34+2Боюсь, что изобретение общего искусственного интеллекта убьет программирование намного раньше.
vintage
26.12.2018 19:48+1Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.
Философия языка — создавать одинаковые проблемы, чтобы их решали одинаковым образом.
SiliconValleyHobo
26.12.2018 20:02-2Видел я таких, «творческих» программистов. И инженеры из них херовые, и пользы для бизнеса не сильно много.
Не надо оправдывать говнокод творчеством. Программы надо писать понятно, прозрачно, эффективно, быстро и стабильно. Ваш же пост все это подводит под хотелки бизнеса и кровавых топ менеджеров, и вообще, мол, это все от лукавого.
А знаете, в чем дело? В том, что вы сами признавались n публикаций назад, что Вы вечный мидл. Максимализм и показушничество.
PS. Если что, я и сам Go не люблю, но по другим причинам. Основной язык С++
xfaetas
26.12.2018 20:11-2Творчеством занимаются маркетологи, дизайнеры и специалисты в предметных областях, которые формируют концепцию продукта. Программисты занимаются переводом этих фич в машинный язык на более низком уровне.
Может быть автор ошибся с профессией: думал, что программист — это такой сумрачный гений и рок-звезда, который решает всё: от списка фич продукта до списка флагов компилятора, а на деле оказалось, что программист — это что-то вроде переводчика, который может переводить, но не может ничего сказать самостоятельно, поскольку самостоятельно говорят другие — компетентные — люди.
Rusllan
26.12.2018 20:15Я согласен с автором в том, что программирование идет по пути бизнеса, но это не программирование, а человечество в целом. Тем не менее, мне кажется, что написание «безликого» кода, хоть и удовлетворяет нуждам бизнеса и всячески им поддерживается, но никак не лишает профессии программиста творчества. Продукт работы программиста не строки кода, которые могут быть безликими, а цельная программа. Это как сводить рисование к тому, как водить кисточкой. Творчество не в том, что ты водил кисточкой каким то особым способом а в том что ты этой кисточкой создал что то новое.
SirEdvin
26.12.2018 20:26+1большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.
И это маркетинговый обман для того, что бы оправдать синтаксическую бедность языка. То есть исключая абсолютную глупость утверждения в плане логики работы кода и прочего, у golang даже синтаксис иногда позволяет сделать одного и тоже разными способами (тут есть немного примеров). Просто не ведитесь на это. Сюда еще можно докинуть управление зависимостей.
Go — это бизнес-эффект, а не инженерное решение. Он сам себе противоречит. Вот он хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности. Дженерики существуют именно ради надёжности, чтобы предвосхищать потенциальные баги dev-time. И да, они довольно сложны.
Мне кажется, вы как раз тут не правы. Go — это очень инженерное решение, просто оно от хардкорных инженеров и для конкретных задач. И в этой области он дает фору в целом всему, потому что другие языки или довольно сложны для этой задачи, или же просто не подходят.
Но вот из-за хайпа go потащили всюду и тут уже пришел бизнес с требованием написания кода быстро и с большим количеством абстракций, что бы сам по себе код был довольно гибок. Вот и приехали дженерики и прочие решения.
JekaMas
26.12.2018 21:35Думаю, вы полностью правы. Go создан программистами старшего чем мы поколения. Со своим видением и опытом. Можно сказать, что этот опыт они включили в язык как набор шаблонов и требований.
*Дженерики не приехали :) Их еще пару лет будут аккуратно смотреть и пробовать.
creker
26.12.2018 22:36-2у golang даже синтаксис иногда позволяет сделать одного и тоже разными способами
И это даже авторами считается досадным упущением, которое они пытались исключить из языка, но не получилось. Сейчас идет второй заход и уже есть предложения убрать эти дублирующие конструкции, но обратная совместимость это вряд ли позволит.
И никакого маркетингового обмана в этом нет. Для кого бедность языка, а для кого прекрасный дизайн языка, позволяющий писать ясный код. Возможность писать одно и тоже разными способами для меня как раз признак низкого качества языка и нагромождения фич. И го был бы еще лучше, если бы в нем, например, убрали new.
Тоже самое с управлением зависимостями. Одна из самых прекрасных фич языка. Сколько проблем и гемора предотвращено просто грамотным дизайном модулей. И проблемы тут возникают только тогда, когда приходишь с другого языка, где можно творить что душе угодно и не важно, чем это обернется в будущем.SirEdvin
26.12.2018 22:43+1И никакого маркетингового обмана в этом нет. Для кого бедность языка, а для кого прекрасный дизайн языка, позволяющий писать ясный код. Возможность писать одно и тоже разными способами для меня как раз признак низкого качества языка и нагромождения фич. И го был бы еще лучше, если бы в нем, например, убрали new.
Ну, фиг с ним с синтаксисом. Но на уровне логики приложения у вас такого не получится достигнуть в целом никогда. А синтаксические трюки дело десятое, на мой взгляд.
Тоже самое с управлением зависимостями. Одна из самых прекрасных фич языка. Сколько проблем и гемора предотвращено просто грамотным дизайном модулей. И проблемы тут возникают только тогда, когда приходишь с другого языка, где можно творить что душе угодно и не важно, чем это обернется в будущем.
Я прошу прощения, это вы про
go mod, который появился сравнительно недавно, а до этого полный трешак сgo getи отсутствием управления зависимостей. Причем каждый другой новый язык с самого начала вводит какие-то пакеты или модули, а вот golang решил отличится.creker
26.12.2018 23:00-2Ну, фиг с ним с синтаксисом. Но на уровне логики приложения у вас такого не получится достигнуть в целом никогда. А синтаксические трюки дело десятое, на мой взгляд.
С этим то я не спорю и вообще непонятно откуда даже такое взялось. Я к тому выше и писал тоже. Смешал все в кучу автор зачем-то. Дублирования нет в языке, но это инструмент. Писать на нем можно что угодно и как угодно. Твори сколько влезет. Просто базовые все конструкции максимально ортогональны, поэтому код на го обычно не нужно расшифровывать. Он предельно ясным получается во многом благодаря такому дизайну языка.
Я прошу прощения, это вы про go mod, который появился сравнительно недавно, а до этого полный трешак с go get и отсутствием управления зависимостей
И про то, и про другое. Это чуждо может быть для других языков, но go get привил подход, когда мастер ветка всегда стабильна. Что go mod к этому добавил, это версионирование, которого действительно не хватало. Каждый решал это сам — сабмодулями в гите, сторонними решениями вроде dep и т.д. В плане тулинга был пробел и тут явно видны ноги гугла с его монорепой, а вот сам дизайн модулей — он сделан прекрасно и одна из лучших фич языка.
Сейчас вот главное, чтобы вендоринг оставили такой, какой есть. А то вместе с go mod убрали его поддержку, но под напором общественности вернули. Правда в каком-то корявом виде с необходимостью передать флаг, чтобы включить ее.SirEdvin
27.12.2018 00:08+1Это чуждо может быть для других языков, но go get привил подход, когда мастер ветка всегда стабильна
Хах, нет. Просто
go getпривел к версинности по коммитам, а в куче проектов как мастер ветка собирается через раз, так это и происходит. В хороших проектах проектах так и без специальных тулзов делают.
int03e
27.12.2018 01:00+3но go get привил подход, когда мастер ветка всегда стабильна.
Вы рассчитываете на определенный API определенной версии библиотеки, и при этом ссылаетесь на ее master branch? Звучит безумно. Он то может быть стабильным, только вот обратной совместимости API никто не гарантирует. Меня это оттолкнуло от GO с самого начала, вместе с идиотским GOPATH и отсутствием эксепшенов. Радует, что первый пункт уже устарел, надеюсь что решили и остальные проблемы.
kot23russia
26.12.2018 20:55Согласен с аффтором… любое укрупнение языков приводит к унификацию и ограничению возможностей разработки… я в принципе не являюсь долбоящером программистом… я инженер… пишу код по мере необходимости, быстро и то что нужно… долго работал в C# скажем так очень просто и много возможностей… однако в определенный момент стало ясно что на целевой платформе на C# слишком границы возможностей сужены… ушел на С++ и оказалось что можно творить то что раньше и не снилось… да вариантов решения одного и того же множество но в этом и прелесть можно создать именно то что нужно а не выбрать из готовых шаблонов…
inew-iborn
26.12.2018 21:20А я всегда говорил что сначала архитектура, потом парадигма, а потом язык программирования… если уж говорить о ЯП
JekaMas
26.12.2018 21:28+1Не могу согласиться с утверждением, что сложность нужна для надежности.
И это не изобретение Go — ограничение языка для более простой и надежной работы. Это просто потомок альтернативной ветви эволюции императивных языков Modula/Oberon/Pascal. В чем-то это детё Вирта. А он всю жизнь именно борьбе со сложностью за надежность и посвятил. Пройдитесь по мшистым форумам Оберона, там все несколько иное, но надо отдать должное, народ пишет умные и надежные системы.
x-foby
26.12.2018 21:59Я не имею ничего против дженериков, но мне до сих пор не понятно, почему в какой-то момент времени их наличие стало критерием качества языка?
Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.SirEdvin
26.12.2018 22:03+2Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.
Если вы не можете нормально писать с перегрузкой функций, то вы, очевидно, не сможете писать нормаль и с ней. Поэтому давайте называть функцию
print,print1,print2.
Дженерики как минимум нужны для универсальных контейнеров, функций и прочей фигни без потери типа. То есть можно делать каст типа обратно, но это не очень удобно.
x-foby
26.12.2018 22:14-3Вы говорите «нужны» там, где следует говорить «удобны».
А вообще мне очень нравится ваше определение: нужны для универсальных контейнеров, функции и прочей фигни.SirEdvin
26.12.2018 22:21+3Вы говорите «нужны» там, где следует говорить «удобны».
Они именно нужны. Потому что если их нет, вы начинаете их эмулировать путем приведение типов туда и обратно.
x-foby
26.12.2018 22:33-2Или, тяжело представить, придумаю, как обойтись без этого?
Не это ли та свобода на отсутствие которой так сетует автор?
Не в том ли проблема, что зачастую дженерики (хоть и, повторюсь, я считаю их хорошим инструментом) в руках непризнанных творцов становятся просто средством латания кривой архитектуры?
Хорошие программисты пишут хорошо на любом языке (кто-то умудряется даже в эзотерические уметь), остальные предпочитают обсуждать «слабые стороны» языков, в которые они не смогли.
Се ля ви.SirEdvin
26.12.2018 22:48+5Возьмите любой крупный проект и погрепайте сколько там приведений к пустому интерфейсу и назад. Почти все эти случаи из-за отсутствия дженериков. Даже больше того, в самом языке массивы — это тоже дженерики, вы без них не можете писать код нормально.
Правда, хорошие программисты могут писать и на ассемблере, но зачем специально вставлять им палки в колеса то?
NecroRomnt
26.12.2018 22:29+4Ну Вы, конечно, молодец, низвели тему беседы к словоблудию.
Можно дерево «срубить» быстро и удобно бензопилой, а можно долго и усердно топором.
Так вот если я ценю время и силы — мне нужна бензопила, если я хочу заняться известным делом, сродни библейскому Ананию, то мне пойдёт и топор, а может и ложка.x-foby
27.12.2018 09:29-3Вашему лагерю пора бы уже определиться: то ли вы за свободу и творчество, то ли за удобные и простые инструменты.
А то когда речь заходит о дженериках, вам подавай готовую спеку языка, предполагающую решать конкретную проблему конкретным способом, во всех остальных случаях у вас этот же подход вызывает истерику и вот такие статьи.
П — последовательность.
Akon32
27.12.2018 15:04Я не имею ничего против дженериков, но мне до сих пор не понятно, почему в какой-то момент времени их наличие стало критерием качества языка?
Один из критериев "качества языка" — возможность лаконично выражать разные абстракции. Простой пример — коллекции элементов различных типов, но не стандартные, а создаваемые пользователем языка (ну, какой-нибудь R-Tree или Trie, или LinkedHashMap, если у вас нет jvm). Для этого могу вспомнить 3 подхода:
1) Динамические языки. В коллекцию можно добавить любой тип, проверки во время компиляции нет. Просто, но наличие юнит-тестов желательно.
2) Копипаст. Адовые заклинания на препроцессоре С, кодогенерация или ручной копипаст. Стандартного способа нет, используются нестандартные, кто во что горазд.
3) Статические языки с generic'ами, ко- и контравариантностью типов-параметров. Позволяют описать коллекцию, наложить ограничения на типы-параметры, проверить ограничения во время компиляции. Сложно, но надёжнее и быстрее, чем динамических языках.
Если ваш язык статически типизован, приходится выбирать между 2 и 3. Подход 2 будет похуже из-за ненаглядности исходного кода, неожиданных ошибок, отсутствие поддержки IDE. Подход 3 сложен, но основная сложность в написании компилятора языка и IDE.
Конечно, если ваши структуры данных настолько просты, что хватает стандартных, вам ни к чему вникать в ковариантность типов и в вот это вот всё. Но для достаточно сложных случаев проще вникнуть, и взять подходящий язык.
timdorohin
27.12.2018 19:39Простой пример — коллекции элементов различных типов, но не стандартные, а создаваемые пользователем языка
«Янепрограммист», но для решения чего-то подобного в чистом C у меня была структура из char'а, указывающего тип и union'а со всеми комбинациями элементов. Это-вот не оно? Я просто не понимаю…
Или речь о том что типы проверять еще на этапе компиляции? Как в шаблонах С++? Но так если в массиве элементы разных типов, то такое не сработает, все-равно придется их в рантайме определять.0xd34df00d
28.12.2018 22:07Но так если в массиве элементы разных типов, то такое не сработает, все-равно придется их в рантайме определять.
Если вы статически знаете множество допустимых типов, то можно хранить ADT с этими типами. Хранить в массиве набор непонятно чего за всю практику мне нужно было… ну, я уже не помню, когда.
epishman
26.12.2018 22:09+4Похоже, Go и придумали как язык для типовых программ, которые могут писать типовые кодеры. Нетиповые программы, где нужно искусство втиснуть 3D-алгоритм в ПЗУ боеголовки, и где нужен Программист — пишутся на других языках. Есть макдональдс а есть шеф-кафе.
s-kozlov
27.12.2018 07:03+4Сложилось ощущение, что автор работает в макдаке и жалуется, что ему не дают делать гамбургеры по своим рецептам.
epishman
27.12.2018 10:34Можно к заказчику уйти, на завод какой-нибудь, там обычно свободы больше но там тоскливо, и новое веяние топ-менеджмента что свои айтишники не нужны.
s-kozlov
27.12.2018 12:23+1На заводе ему тем более никто не даст вылизывать код просто потому, что это невыгодно.
epishman
27.12.2018 12:27Бывает что и даст. Я полжизни проработал у заказчиков, там с тайм-менеджментом в основном никак, то есть сидит доверенный ИТ-директор-по-закупке-оборудования, и если ты хороший программист — тебя могут вообще полгода не трогать, пока что-то не случилось. А сисадминам на заводах вообще рай. А вот в ИТ-компаниях тайм-менеджмент довольно жесткий, потому что они в среднем беднее, потому и менеджмент у них более капиталистический.
s-kozlov
27.12.2018 13:19Ну то есть это тот вариант, когда программисту нечем заняться. Сомнительное удовольствие.
BorlandDelphi
27.12.2018 12:28+1На заводе ему тем более никто не даст вылизывать код просто потому, что это невыгодно.
Если оборудование выпускаемое заводом имеет ограничение памяти в 128 килобайт, а код в этот лимит не лезет, то код вылизывать ПРИДЁТСЯ.
Neikist
27.12.2018 12:32+2Да нет, обычно как раз слышно что времени просто куча в таких местах свободного. Задачу сделал что поставили — и сиди, занимайся чем хочешь. Не везде, понятно, но много где. Правда там и платят меньше, года полтора назад например спрашивали не хочу ли к ним пойти на 20к ЗП (не миллионник), при том что это бы даже тогда означало бы проседание по ЗП в полтора раза. А сейчас и вовсе в 2.5. Свободное время это конечно хорошо, но 20к даже для нашего городка копейки.
faustov14
26.12.2018 22:17-2Чем больше что-то развивается, тем больше упрощаются и универсиализируются его элементы. Так будет и с программированием. После упрощения языков программирования и выработке универсальных подходов, будет создано проф. ПО, которое даст возможность создавать код не программисту, а простому выпускнику ПТУ. Зародыши уже есть в виде визуальных редакторов кода, но новое ПО будет намного серьезней. И это все, может, плохо для программера, но очень хорошо для всех остальных.
kot23russia
26.12.2018 23:40Да нонче программисты и есть выпускники ПТУ… ну как бы очень часто слышу от программистов «данная задача не гуглица, ну значит она ни кому не нужна, нахер нам этим заморачиваться»…
PerlPower
27.12.2018 04:27+2Каждый раз эта идея вырождается в набор строительных блоков для какой-то одной предметной области. В лучшем случае вокруг предметной области появляется богатая инфраструктура готовых решений, тому пример CMS и движки веб-коммерции, но все равно весь фриланс забит заказами на допиливание оных. Хотя казалось бы, куда уж стандартней?
KostaArnorsky
27.12.2018 04:51+4Уже были CASE-системы, и где они? А UML с кодогенерацией? А про IDEF_ вы помните?
Несомненно, скоро какие-то задачи будут автоматизироваться простым наговариванием электронному ассистенту, но до упрощения разработки прочти как до ИИ, пока что она только усложняется. Проще стало решать вчерашние задачи, это да, но с развитием возможностей растут и запросы.
unclechu
26.12.2018 22:30+3Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Как б-женька смолвил, чуть не расплакался. Всегда стараюсь искать работу с тех. стеком, отбрасывающим на входе как можно больше бездарей и вредителей (например такие, которые делают
rm -rf tests/, если у них перестали проходить какие-то тесты, когда их на недельку оставили одних в проекте, случай из личной жизни), тем временем вижу всё меньше хороших вакансий, и кругом всюду требуются сплоншняком PHP/JS/Python/Ruby/Go-говноклады. Тенденция давно задана, и средний уровень престижа профессии стремится пробить всё новое дно. Хорошее программирование не будет убито, оно и так уже почти мертво.
ijsgaus
26.12.2018 22:39+1Проблема в том, что автор прав до определенного предела. До тех пор пока этот безликий подход приносит деньги. Но наступает предел. Предел безпомощности и ошибок слабограмотных специалистов. Когда софт перестает давать деньги, и когда бизнес вдруг оказывается без возможности удовлетворять потребности. И тогда специалисты, настоящие, оказываются нужнее. И это ОБЫЧНЫЙ результат бизнеса, который делает все быстро, мало того закономерный и прогнозируемый. Поэтому — безликий простой код — удел стартапов. А потом начинается путь Facebook, Google и иже с ними — свои компиляторы, библиотеки, опережающие все, что было до этого, вот тогда мы — настоящие фанатики своего дела и начинаем быть востребованы. Бизнем должен ушибиться. Тогда он умнеет.
justjeckill1993
26.12.2018 22:40+3Начал читать, не посмотрев автора, всю статью казалось, что мне знаком этот стиль от которого веет самолюбованием и завышенным чсв, но после слов «любой лох посидит на курсах год», не поверите, я узнал автора)) Специально посмотрел в конце и вообще не удивился своим «экстрасенсорным» навыкам)
По поводу статьи в целом можно согласиться, к сожалению, давно пройден тот этап, когда ИТ действительно жило прогрессом, даже менталитет сферы был другим, сейчас же даже начинающих туда влечет больше денежная и бизнес-составляющая, к сожалению, а каков запрос, такое предложение… печально
vba
26.12.2018 23:20+2то мы придем к самой кривой и не оптимизированной автоматизации, какую только можно представить.
Ничего гугл что-нибудь новое запилит для оптимизации неоптимизированной автоматизации, GoPTimizer. Согласен с автором, Go это какое-то обезличивание программирования.
strawberrycheese
26.12.2018 23:49Хмм..., сам никогда не понимал, зачем снижать порог входа в область.
Это же ведь натуральный отсев, кто сможет преодолеть, а кто нет.
В итоге качество станет только лучше.
Хотя понятно, что до какой-то степени материал нужно делать понятным для других.
index0h
27.12.2018 00:14+5Не понимаю автора со всей силы. Безликий код — это отлично. В моей практике, к сожалению, "творчество" чаще всего выражается в не следовании стандартам и не очевидным решениям, над которым далее приходится ломать голову, бывает по несколько дней. С комментариями в стиле "добавь к счетчику, сколько времени ты потратил на это метод".
Особенно это касается больших проектов на десятки/сотни программистов. Как показывает (моя) практика — чем строже стандарты, кодстайлы и вот это вот все — тем лучше. То, что в Go-шке сделали gofmt и утвердили стандарт оформления — это замечательно. Сообществу PHP на понимание необходимости такого стандарта потребовалось более 10 лет!
Zanak
27.12.2018 00:24+2Возможно автор мнит себя Моцартом, а на самом деле он только Сальери.
Творчество сосредоточено не там, где автор пытается его искать. Разработка готового продукта под требования клиента — это, как правило, ремесло. Разработка новых решений, на основе которых строятся готовые продукты, это творчество, придумать nginx, во времена, когда альтернатив апачу не было, это творчество, задуматься о NoSQL, когда везде был только SQL, это творчество. Появляются новые языки, как результат осмысления прошлого опыта, и пусть не все из них останутся на десятилетия, как Си или Джава, сам факт их появления — это тоже мысль и творчество.
Есть желание творить? Определитесь со своими предпочтениями, и творите на здоровье. Например язык Rust, начинался как проект одного человека, а сейчас его перспективы весьма не плохие.
DexterHD
27.12.2018 00:42+1У автора дар разжигать. Причем разжигать грамотно, себе в плюс. :) Я бы порекомендовал посмотреть интервью с автором, чтобы понять откуда ноги растут habr.com/post/420321
Lissov
27.12.2018 01:28+1Программирование движется по пути всех предыдущих профессий. И я бы не стал примешивать сюда ИИ и автоматизацию — можно с ними, можно без них, картина та же.
Несколько тысяч лед назад спроектировать двухэтажный дом могли единицы. И им нужны были сотни а то и тысячи носильщиков камней. Потом появились «типовые архитекторы», которые должны были проектировать по типовым схемам и проектам, но мы всё ещё знаем имено «творцов» (например Растрелли). А типовые архитекторы видимо возмущались, что им не дают творить. Теперь таких типовых архитекторов вероятно можно заменить софтом — никому не нужно творчество в прокладке труб в туалетах. Однако остались как гении уровня Захи Хадид и Хундертвассера, так и просто местные архитекторы, в результате творчества которых в моём районе все дома немного необычные. Плюс тут в том, что милиарды человек имеют крышу над головой, при этом не переживают, что это нестандартное решение развалится от порыва ветра.
С одной стороны, многих кодеров как и архитекторов, прокладывающих трубы, можно будет заменить автоматизацией. С другой, всегда останутся те, кто будут очерчивать общие контуры домов или софта, а дома и софт буду становиться дешевле, доступнее, массовее. Нужно всего лишь продолжать развиваться.
morgot
27.12.2018 03:19+1К сожалению, деньги еще не отменили, поэтому нужно писать не то, что хочется, а то, что требуют. Но это не значит, что нужно делать это круглосуточно. Выделите время на хобби и пишите в свое удовольствие.
Я вот пишу для себя на Ассемблере Масм в npp — никаких «умных компиляторов», «умных IDE» и прочего. Только творчество, эксперименты. На заказ, к сожалению, это будет слишком долго и никому не нужно. Но, для работы на заказ есть другие вещи, скажем, C++17 и Visual Studio.
VIkrom
27.12.2018 05:01+2Программируя, я хочу заниматься творчеством.
Каждый раз слыша подобное хочется спросить, какой срок автор высказывания программирует за деньги? Потому что все эти «творческие» душевные порывы улетучиваются в коммерческом программировании году так на втором.
Хочется творчества — пилите личные проекты. Программирование для бизнеса это ремесло.
JustMoose
27.12.2018 09:28+1Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Есть подозрение, что порог входа и так слишком высокий. Только не потому, что кто-то так специально сделал. А потому что софт/инструменты/языки/конечные продукты — сырые. (Самое время вспомнить байку про Джона — серийного программиста). И виноваты в этом все ;) С одной стороны бизнес, который не даёт время сделать хорошо. С другой стороны программист, который занимается избыточным перфекционизмом там, где можно было бы сделать просто. Да и вообще, просто — это не всегда плохо. Часто это хорошо :)
zim32
27.12.2018 09:56Да грустно наверное автору. Думал вот плтрачу пол жизни буду изучать все и стану крутым программистом незаменимым супепстаром и покажу всем кто тут самый умный. А в итоге профессия поменялась так сильно что любой новоиспеченный мидл ничем не хуже тебя.
lotse8
27.12.2018 10:05+6Проблема в том, что Пикассо устраивается в бригаду маляров, которые красят стены или заборы и получают оплату за покрашенные квадратные метры, а не за изящество мазка кисти. Маляры на гениальность не претендуют и довольны зарплатой, а Пикассо страдает. В этом бизнесе Пикассо лишний. Такова суровая правда жизни.
nerudo
27.12.2018 11:29+7Правда жизни еще суровее: маляр может воображать себя Пикассо, вынужденным работать маляром.
olegmar
27.12.2018 10:20+1Кажется, что автор чем-то обижен на Go. Может его набирающей оборот популярности? А на самом деле Go абсолютно не отменяет никакие парадигмы программирования, практики и шаблоны. И на Go можно написать плохую программу.
EnotovaMorda
27.12.2018 10:28-2Коллеги, меня все это зацепило, как написал выше. Но! Как показывает многолетний опыт разработки — реально мало профессионалов… Найти C# прокачанного программиста — проблема. Да вообще в любой среде… Надо прособеседовать кучу людей, и то не факт, что найдешь. И дело не в деньгах. Так что миддлы на то миддлы. Никогда не обгонят, если не будут учится.
FYR
27.12.2018 10:45+1Не парься бро. Когда появились фотография тоже говорили: вот все теперь художники вымрут, тоже самое было с театр vs кино, кино vs TV, TV vs internet.
Да появятся ремесленники от программирования, потом их заменят автогенераторами, но «художники» которые смогут реализовать идею «изящно» всегда будут.
AndreyGaskov
27.12.2018 10:52+1Да, есть такая проблема, когда хочется быть свободным художником, а зарплату получать по тарифу (XX$/час). Надо выбрать что-то одно из двух. Или можно быть художником на бюджете у корпорации (R&D, например). Только для этого надо быть ещё и очень крутым (чтобы пройти отбор из кучи человек на место), и везучим.
Sly_tom_cat
27.12.2018 11:05Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар.
Хочу вас расстроить, но этот хоорор уже вокруг нас.
Сейчас вы можете писать очень много умных вещей, но компилятор потом все ваши умности конвертнет в векторные вычисления и прочие совершенно нечеловеческие паттерны. Нечеловеческие в том с смысле что такой код люди написать конечно могут, но потом прочитать и понято что этот код делает смогут не многие и не сразу.
zeolant
27.12.2018 11:21А вы не пробовали начинать получать удовольствие от процесса а не от результата (пусть за результат болит голова у менеджера)? Вы продумали архитектуру, нашли интересные пути реализации, написали код, и вот программа заработала. Я, например, лично от этого и получаю удовольствие, а как ей потом будут пользоваться, по сути не имеет значения (даже если никто не будет пользоваться, я не обижусь), я свою порцию «наркотика» получил.
Как в старом анекдотеЖенщина в магазине просит отпустить ей 30 метров бязи. — А зачем Вам так много? — интересуется продавец. — Я хочу сшить себе ночную рубашку. — Ну, на рубашку Вам в 3-х метров хватит. — Дело в том, что мой муж научный работник, и его процесс поиска интересует больше, чем результат.pipl
27.12.2018 11:41Если в Go каждая задача имеет только одно решение, то значит это и не язык программирования вовсе. Это некая сжатая библиотека (кодовая база), для разжатия нужного сегмента которой требуется программист.
Можно ещё провести аналогию с ДНК…
Gorthauer87
27.12.2018 11:59+2Необходимость в сложных алгоритмах и архитектурных решениях никакая стандартизация и безликость кода не убъет. К счастью или к сожалению, таких задач их меньше, а для обычного штамповочного кода подойдет и конвеер.
Так что если не нравится быть оператором конвеера, то стоит все-таки углублять свои фундаментальные знания и способности к самообучению и идти уже в системные программисты, а не прикладные.
Newbilius
27.12.2018 12:02Потому что готовый продукт важнее его реализации.
Да, да, тысячи раз ДА! Это же самый-самый кайф! Вот ты доделываешь фичу, выкатываешь в продакшен — и жизнь пользователя становится чуточку лучше. У него меньше головных болей, потому что сервис что-то автоматизировал, что-то теперь не нужно делать руками… Или он благодаря твоей работе может интересно провести время, получить удовольствие или расслабиться — привет компьютерные игры, браузеры и т.п. Разве это не офигенно само по себе, что относительно небольшими усилиями ты хотя бы чуточку меняешь жизнь других людей? О_о
Из похожего — съёмки развлекательных видео например. За этот год у меня на махоньком ютубовском канале (40 тысяч подписчиков) зрители насмотрели 2 миллиона просмотров. 22 миллиона минут. 40 человеко-лет. Хотя я со своей стороны затратил за год на эти видео суммарно даже не человеко-месяца. Это же… обалдеть какое соотношение усилий/результата, если попытаться в голове удержать!
Ну и блин, как можно не находить творческих задач даже в «текучке»? Да любая, даже самая шаблонная задача всегда содержит простор для размышлений! Как поменять наименьшее число слоёв, чтобы передать данные отсюда сюда? Как оптимальней распределить работу между клиентов и сервером? Или вот мы делаем в месяц 2-3 рутинные задачи такого типа — как бы это автоматизировать, чтобы рутины вот конкретно здесь стало меньше? И такие задачи на каждом, блин, шагу!
rgrits
27.12.2018 13:02+2К вопросу о том что убьёт программирование: 20 лет назад говорили о том что кейс-средства убьют программирование. И где те кейс-средства? Есть идеи, почему не убили?
s-kozlov
27.12.2018 13:23Есть идеи, почему не убили?
Есть — в самом начале «Чистого кода» дяди Боба:
Нам даже доводилось слышать мнение, что код как таковой скоро
перестанет существовать. Что скоро весь код будет генерироваться, а не писаться
вручную. Что программисты станут попросту не нужны, потому что бизнесмены
будут генерировать программы по спецификациям.
Ерунда! Код никогда не исчезнет, потому что код представляет подробности
требований. На определенном уровне эти подробности невозможно игнорировать
или абстрагировать; их приходится определять. А когда требования определяются
настолько подробно, чтобы они могли быть выполнены компьютером, это и есть
программирование. А их определение есть код.
dzolotarev
27.12.2018 13:18+1Начало неплохое. Те же мысли посещают. Но насчет одинакового кода однозначно перегиб. Код и должен быть одинаковым, подчиняться гайдам, стандартам, соглашениям. Иначе потом рехнешься разгребать то, что накреативила очередная творческая личность.
sergey_z777
27.12.2018 13:18Я бы посоветовал автору почитать вот это: The 10 rules of a Zen programmer, особенно обратить внимание на часть 4.
8gen
27.12.2018 13:18+1Не убудет у нас работы. Простота кода в восполнится сложностью в чём-то другом. Сейчас это инфраструктура в которой он будет выполняться (microservices, orchestration, containerization,… с чем там ещё сейчас сложно).
Так что работа будет, может просто не совсем в такой форме
ArchkWay
27.12.2018 13:18+5Ох уж эти кодеры-элитисты, от них всё зло. Ими движет банальный страх остаться не востребованным, а не радение за "ИСКУССТВО КОДИНГА".
Хочется тебе нечто большего?
Есть ощущение, что ты делаешь ТУПОЕ ГОВНО, ДЛЯ ТУПОГО ГОВНА?
— Ну так развивайся!
Меняй специализацию, изучай новые фишки, куча интересной фигни в этом вашем IT: II, Machine Learning, VR, BlockChain.
Вперёд! Пиши свои мудрёные и изящные алгоритмы, задавай стандарты! А не ворчи, как старый дед, про то какие все вокруг бездари.
interesnay
27.12.2018 14:14Не всем дано понять Пикасо, вот вы скажите, лучше ли его картины, чем у нашего Репина? Вы хотите самовыражаться, и не все люди могут это понять, поэтому им нужны простые решения.
EvilsInterrupt
27.12.2018 15:16-1Нужно обычное. Потому что готовый продукт важнее его реализации.
Таки да!
Вот к примеру, беру сейчас мобилу в руки и если честно, то я понятия не имею как много раз разработчики прошивки и программ писали goto? Меня лишь заботит исключительно функциональность и производительность относительно моего субьективного представления. К примеру, если я считаю, что смс-ка должна отправиться за 1 сек., а отправляется за 7-10 сек., то мне абсолютно до лампочки как много хороших практик применил разработчик в коде отправки смс-ки! И так думает почти 95% пользователей ПО.
Далее. Чисто из экономических соображений. N руб. сегодня не равно N руб. завтра! Есть инфляция. Если вы провозитесь с решением на K дней больше находясь в поисках хорошего варианта, хотя можно было написать пусть не идеальное, но рабочее и качественное решение и за это время продукт из-за инфляции упал на 1 руб., то в случае с 1.000.000 пользователей это 1.000.000 руб. А за эти деньги можно много чего для бизнеса решить, к примеру выдать вам зарплату!
Позиция «Мне платят за выбор из разного вариантов лучшее» — ошибочна! Вам платят за решение рабочих задач на уровне «Необходимо и достаточно».
Вы, как разработчик, абсолютно ничем не рискуете. Легко можете поднять мягкое место и найти другого работодателя, который будет вам выдавать новые задачи. А вот работодатель рискует! Продолбанные сроки перед заказчиками — факап. Неуспели поставить пользователям билд, а уже новый год встречают и они не работают и как вывод не покупают софт — факап. И много много других факапов может быть из-за «Я искал лучшее решение». А потом к работодателю приходит Вася и говорит «Я вот тут работал и искал лучшее решение. Месяц прошел. Выдавайте зарплату» и ему как правило насрать, а сумел ли работодатель продать софт или нетun1t
27.12.2018 16:30Вы правы, что риски не на разработчики, а на владельце бизнеса. Но ведь и прибыль достается не разработчику, а владельцу бизнеса.
Тут есть очевидный конфликт интересов.
Бизнес заинтересован, чтобы разработчик день ото дня методично выкатывал нужные фичи с приемлемым качеством, т.е. выполнял тупую рутинную, невероятно скучную работу.
Разработчика волнует свой карьерный рост и чтобы работа была хотя бы иногда интересной. Если он не будет изучать новые технологии, то завтра его выкинут с той же работы и наймут, новых которые знают современные языки, фреймворки, платформы. Он пробует всякие новые языки, фреймворки, технологии, подходы и архитектурные решения, которые очень часто бывают плохим решением данной задачи, но хорошии для будущих проектов и карьеры.
EvilsInterrupt
27.12.2018 16:43Уверяю вас, в мире разработки очень много интересных задач и при этом хорошо оплачиваемых. Не надо просто замыкаться только и только в одном куске разработки. Разработка она большая! Это большая вселенная! И надо просто поднимать голову из своего болота, хотя бы изредка и смотреть по сторонам. Тогда интересы многих сторон будут соблюдены, в том числе и интересы разработчика
Neikist
27.12.2018 16:44+1Будем честными, интересной работы на всех просто не хватит) А способности и навыки объективно у всех разные)
EvilsInterrupt
27.12.2018 17:12+1Будем честными интересной работы чуть более чем дохрена!
Есть люди ничем не интересующиеся, к примеру от них можно услышать: «а зачем мне марофон пробегать?» или «А зачем мне в хакатоне учавствовать?» или «А зачем мне на лыжи идти?» или «А зачем мне куда-то ехать пострелять?» или <подставьте, что придет в голову>. Им в принципе вообще не интересно! Уперлись только в одно занятие и сидят в нем.
А есть другие! Они и IronMan-ы проходят. И марафоны бегут. Еще и для мобилы аппликуху запилят и еще 100500 всего. Им все интересно! Как правило у них другой вопрос «Где на все взять время?» ведь все так интересно.
По поводу способностей и навыков: все развивается!
До августа 2016-го я умел плыть только одним стилем «топор ко дну», а в июле текущего 2018-го переплыл Босфор. В прошлом году понятия не имел что такое Promise, а сейчас не только его, но и async\await пишу и не особо боюсь и много чего другого тоже применяю.
было бы желание!Vantela
27.12.2018 17:22+1Босфор? Круто! А я много лет лелею идею переплыть Гибралтар. Чтобы из Европы в Африку.
Но сейчас читая про Босфор, я понимаю, что надо бы мне с него начать… Гибралтар сильно круче.
Neikist
27.12.2018 19:48Ну смотрите, у нас пяток миллионов интересующихся. И всего миллион вакансий. Хочешь не хочешь — а 4 миллиона в пролете. К слову они и… и… и… — больше минус. Я сам такой что прихожу домой с работы и то новый ЯП изучаю, то пару иностранных учу, то рисовать пробую, то сажусь на велосипед и еду на весь день кататься, да еще и лелею мысль когда нибудь математику подтянуть хорошенько. Сейчас вот меняю полностью стек технологий с 1с на android нативный потому что в 1с стало скучно а андроид интересен. В итоге что? Правильно, из меня и программист так себе, и велосипедист, и языки эти я знаю через пень колоду (в японском пока даже до N5 не добрался, но хоть английский более менее) и прочее в таком духе.
P.S. Несмотря на все эти минусы мне нравится мой стиль жизни, но при этом я прекрасно понимаю что такое распыление скорее всего отсечет меня от интересных мест работы. Я не попаду в те самые 0.1% программистов которые чем то интересным занимаются. Точнее не совсем так, мне было в какой то мере интересно и то чем я занимался раньше, и то чем буду заниматься теперь, но это не настолько интересные занятия чтобы отдать им вообще все свое время.EvilsInterrupt
28.12.2018 16:28В итоге что? Правильно, из меня и программист так себе, и велосипедист, и языки эти я знаю через пень колоду
Почему посредственный?
Вы не задумывались о том, что может быть вам еще каких-то навыков не хватает? Что к примеру у вас с английским? А умеете ли вы продавать идеи? К примеру убедить коллег использовать ту или иную технологию это тоже «продажи».
Огромное кол-во людей стукнувшись о трудность думают, что он сделал все что мог. Буквально недавно у меня был затык в webpack-конфиге. Я реально думал, что меня уже гугл матом посылает. Оказалось, что нет, что можно по-гуглить чуть чуть по-другому и проблема решается.
Это про то, что сделанные нами выводы не факт что истина.Neikist
29.12.2018 10:37Почему посредственный?
Ну как, алгоритмы и структуры данных знаю очень плохо, ОС писать не умею, математику знаю на уровне школы, и еще много похожих пунктов. У меня Скиена до сих пор не прочитанный, как и «Дискретная математика для программистов», как и таненбаум, как и банда 4-х, как и многие другие нужные книги из за того что времени много на другие интересы уходит.
ganqqwerty
27.12.2018 15:25+1Наблюдаем тут утопические чаяния программистов вернуть утерянное положение средневекового кустаря. Бизнесу не нужны гениальные кустари-кузнецы, которые могут диктовать зарплаты и посылать начальников на три буквы. Бизнесу нужен штамповочный станок по металлу, полная заменяемость работников, способность обучить новопришедшего за пару дней после приема на работу и побольше безработных кандидатов за дверьми на то, чтобы в любой момент восполнить потери персонала.
ganqqwerty
27.12.2018 16:00+2Загляните на главную страницу докера и поймите, какие образы вызывают у владельцев бизнеса эректильную реакцию: конвейер и панель с тремя кнопками, а не ваши левшовые фантазии.
MR12
27.12.2018 19:30У бизнеса свои чаяния, а у программистов — свои. В чём-то они могут совпадать, а в чём-то — отличаться. И тут нельзя сказать, что интересы одной стороны однозначно важнее другой — это будет чрезмерным упрощением. Должен быть некоторый взаимовыгодный баланс. А так-то можно дойти до того, что бизнес вообще был бы не против, чтобы программист работал 24/7 и желательно бесплатно, но такого к счастью не бывает.
ganqqwerty
27.12.2018 19:43я не думаю, что здесь уместно сравнивать важность данных интересов, неясно ведь, для кого эта важность. Зато мы можем точно сказать, что сообществу программистов важнее собственные интересы, а сообществу собственников бизнеса — собственные.
MR12
27.12.2018 21:06Просто по вашей изначальной фразе можно подумать, что пожелания бизнеса важнее, он платит деньги и соответственно диктует что тут и как. И, соответсвенно программисты должны подстраиваться под эти хотелки. Но на практике-то видится совсем другая картина: именно бизнес бегает за программистами, сбиваясь с ног, за любые деньги, обещая немереные плюшки. Среди которых м.б. и творческий процесс в том числе. Так что не всё так плохо, как кажется. Это пока ещё наши программисты научились требовать только денег. А скоро, как только привыкнут к достатку, и этого покажется мало. Тогда среди требований появится и нескучная работа, вот увидите.
ganqqwerty
28.12.2018 12:25Нет-нет, ни в коем случае. Выполняться будут желания тех, у кого сила. Сейчас сила программистов в их востребованности и слабой насыщенности рынка. При насыщении рынка спецами сила перейдет к владельцам бизнеса. При объединении программистов в профсоюзы — обратно перетечет к ним.
tuxi
27.12.2018 15:32+1Какая классная (без сарказма) получилась дискуссия. Читая комментария и высказывания, сформулировал себя на пару выводов. Первый вывод: я всегда был наиболее счастлив, когда начинал изучать/экспериментировать с новым ЯП. Тот самый, «ламповый» фан/драйв/адреналин когда «ура, ура, оно заработало!!!».
Второй вывод: наиболее удовлетворенным я бываю, когда вижу, что у меня есть выбор, на каком ЯП я могу решить ту или иную задачу (ессно когда нет ограничений в стеке). Т.е. нет плохих языков, просто есть задачи которые для них не подходят.
И да, забыл внести свою лепту в обсуждение: GO интересный язык. Прикольный :) Его ограничения и заставляют как раз заниматься тем самым творчеством :) И иногда, сделав рефакторинг архитектуры, чтобы убрать свои фантастически красивые костыли, понимаешь в чем был смысл этих ограничений. Да собственно говоря это наверное к любому ЯП относится.
newartix
27.12.2018 16:12+1Не соглашусь, что ИТ это 99% развлекалово и делается только для зарабатывания бабла. ИТ это не только и не столько интернет и социалки. Да, сейчас маятник качнулся в эту сторону, но кажется он уже остановился в состоянии покоя и начинает двигаться обратно, в технологическое будущее. ИТ в первую очередь служит цели повышения эффективности всех сфер деятельности человека, в том числе производства, космических программ и научно-исследовательской деятельности.
И уж какую вы выбрали сферу, вопрос только к вам.
Вот как раз появление технологий «программист не нужен» и отделит зёрна от плевел. Тот кто может придумать что-то лучше чем машина — всегда найдёт применение своим талантам, а любители копипасты уйдут с рынка. Это ведь то к чему вы стремитесь?
dempfi
27.12.2018 16:18ТС, если хочешь и денег и творчества — иди в ресёрч отдел какой-нибудь большой компании. Там тебе и денег много дадут и твори сколько влезет интересные вещи.
Вот тебе совет. Найди контакт (вот тебе твиттер @lorentzframe) Браяна Бэкмана (он очень дружелюбный и открытой человек) из бывшего Microsoft Research и текущего Amazon Robotics; спроси у него как попасть в этот самый Microsoft Research; набери скиллов которых ещё нет и стучись к ним. Дерзай, в общем!
achekalin
27.12.2018 16:30+1В посте много уважения менеджерам, вроде как они всегда умные и всегда принимают решения, на чем-то рациональном основанные. Это не всегда так.
Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.
С тем же успехом можно сказать, что сегодня любой вчерашний лох-продавала из салона сотовой связи, выбившись в топы, будет указывать всем, как жить.
Что сказать? Ищи место, где боссы адекватны, готовы платить за творчество, и влияй на развитие этого места. Открой курсы программирования, в конце концов, и — твори!
stranger777
27.12.2018 16:47Мои мозги обслуживают мелкие ежеминутные хотелки, чтобы люди принесли мне деньги, чтобы я тоже удовлетворил свои хотелки.
Краткое и точное описание любой работы. Мы берём чужую лень, свой мозг (рыбное филе, например, порубить — тоже мозг нужен) и трудимся на неё и за это получаем возможность воплотить свои хотелки и быть ленивыми вне своих областей.
И тем более это справедливо для бизнеса. Бизнес ориентирован на людей и их нужды здесь и сейчас. И это нормально.
Если же Вам хочется и вклад в человечество сделать, и творчеством при этом заниматься, и иметь гарантированный кусок хлеба без давления временных сроков и прочих бизнес-радостей, то надо идти в науку. В разработку действительно сложных, долгосрочных систем для будущего, в разработке которых нужен весь мозг и ещё столько же. Но там, за возможность спокойно жить и творить, отнимают хотелки: финансировние бюджетное, от спонсоров проекта — в лучшем случае. Ну, Вы всё это и так знаете, в общем-то.
darksshvein
27.12.2018 17:21>Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом.
или наоборот))
бизнес плох только тем, что использует любой кусок гуано, если он дешевле других решений. так мы пришли к докерам и оргиям в ansible. и жирнолисам.
asorkin
27.12.2018 17:46Система, где все задачи будут решаться только одним способом — это точно не про язык программирования. Всё-таки, это система «полная по Тьюрингу», то есть в ней можно реализовать (теоретически) любой алгоритм.
А то, что происходит автоматический контроль стандарта оформления кода — так это прекрасно! Если есть автоматический контроль, значит где-то рядом есть (или будет) автоматический «бьютифаер». Не нравится имеющийся стиль — переформатировал, так как тебе удобно, поработал, накатил старый «корпоративный» стиль, отправил в Git. В чём проблема?
В Питоне, например, нет скобок и нужно, блин, использовать отступы — это что, ужас-ужас? Да, нас лишили стиля «кирпич кода», однако никто от этого не умер.
иллюстрация из статьи Cryptographic obfuscation and ‘unhackable’ software0xd34df00d
27.12.2018 19:04Ну, к слову о полноте по Тьюрингу, есть главные нумерации, в которых каждый алгоритм имеет бесконечное число номеров, и есть произвольно экзотические неглавные нумерации, включая такия, где у каждого алгоритма ровно один номер (и их можно даже алгоритмически строить из главных).
li4inka
27.12.2018 17:47Иммигрант Де'Анджело ехал в поезде из Нью-Йорка в Релли, в Северную Калифорнию. На вокзале его встретил двоюродный брат, и тот заметил, что он был в паршивом настроении.
«Что с тобой случилось?» — спросил его родственник.
«Этот чертов кондуктор все время указывал мне, что делать и чего делать нельзя,- воскликнул итальянец. — Я вытащил сэндвич, а он мне говорит: 'Это тебе не столовая', я налил себе стаканчик вина, а он мне говорит: 'Это тебе не бар', и тогда я не выдержал и отправился в вагон-ресторан, познакомился там с одной симпатичной девчушкой, она повела меня в свое пустое купе, и тут прибежал этот чертов кондуктор, и начал орать под ухо: 'Это тебе не Вирджиния, это тебе не тра****ая Вирджиния'».
Вы понимаете только то, что можете понять. Ваш мозг всегда все объясняет, но эти объяснения — ваши собственные.
jetcar
27.12.2018 18:36+1программирование никогда не умрёт, может видоизмениться, как например сейчас мало кто пишет используя команды для процессора, инструменты изменились, много уже написано, стало проще и быстрее писать простые вещи и это привело к тому что бизнес стал использовать освободившиеся ресурсы и просто стал использовать то что раньше было дорого и так будет всегда, как только писать становиться проще, начинают количество и сложность фич резко увеличивается и всё опять на том же уровне где и было раньше.
Тут главное следить за технологиями и вовремя на них переходить, и тогда проблем с тем что работодатель захочет тебя заменить никогда не возникнет
Fatik
27.12.2018 19:29Программирование, это прежде всего инженерная дисциплина. Унификация подходов в разработке это хорошо. Если вы претендуете на звание инженера, то надо понимать, что поддержка кода стоит денег причем больших денег. И это дествительно важно. Если вы пишите модуль для поддержки которого требуются дорогой специалист, то это плохой инженеринг. Хороший инженеринг, это когда пишется модуль и его может поддерживать специалист любой квалификации, знающий язык программирования. Именно в этом и есть творчество, то есть разработать простую и элегантную архитетуру.
Если хотите разрабатывать сложные модули, делайте это бесплатно.
Мир устроен так, что программирование ради бизнеса, а не наоборот. И когда вы разрабатываете сложный модуль, то вы увеличиваете стоимость продукта для пользователей.
Вас возможно кто-то учил рациональности, но у этого кого-то мало что получилось. Нет ничего рационального в том что писать код в авторском стиле.
Код это не произведение исскуства, вся суть кода в том чтобы удовлетворить потребность пользователя, пусть даже низменную. А программисты это всего лишь высокоплачиваемый персонал, который обслуживает потребность пользователя. Пользователь с самыми низменными потребностями куда важней программиста.
Конечно можно заниматься творчеством, но это должно быть максимально дешево для пользователяSirEdvin
27.12.2018 20:28+1Программирование, это прежде всего инженерная дисциплина
Не-а. У нас тут в программировании нет практически никаких инженерных метрик, инженерных подходов и в целом какой либо инженерности. То есть, формально можно обмазаться различным computer science, пафосно рассуждать про проектирование систем и прочее, но факты говорят сами за себя:
- Computer science безумно оторван от реальности программирования за рамками каких-то базовых дисциплин. Это проявляется во всем, от научных статей по нейронкам, результаты которых реализуются каким-то школьником с питоном минут за 15, до безумно сложной науки о сервисах, в которых они рисуют воздушные замки с веб-онтологиями.
- Инженерного подхода к ПО в целом тоже исчезающе мало, в целом технологии выбираются на хайпе или же фокусируясь на одном аспекте технологии (она быстрая, надо брать!).
- Инженерной документации по проекту, да и в целом документации очень мало. Нет, правда, вы недавно видели актуальную проектную документацию не в коде, а вот что бы прямо проект-проект?
- Вы только подумайте, у нас ведутся споры о том, нужна ли программисту математика. Можете представить себе такой спор в какой-то инженерной специальности? Думаю, нет.
- Вся теория о том, как правильно программировать покрыта дикой, неформализованной субъективщиной с кучей trade-off. Не очень по инженерному, на мой взгляд.
Ну и да:
Если вы пишите модуль для поддержки которого требуются дорогой специалист, то это плохой инженеринг. Хороший инженеринг, это когда пишется модуль и его может поддерживать специалист любой квалификации, знающий язык программирования.
Такого никогда не будет. У вас в любом случае будет или сложная система, или система, которая умеет довольно мало вещей. В первом случае сложность спрятать не получится, так что специалисту нужно будет в этом как-то разобраться, а во втором случае система скоро будет не нужна. Некоторые специалисты не могут разобраться, скажем, с очередью задач. И что, предложите без нее проектировать?
MR12
27.12.2018 20:56Хороший инженеринг, это когда пишется модуль и его может поддерживать специалист любой квалификации, знающий язык программирования
Если модуль выполняет сложную задачу, то и код его будет сложным, и его не сможет поддержать специалист любой квалификации. Такого, чтобы вы могли заткнуть любым школьником дыру после ухода сеньора, не будет, это розовые фантазии работодателя. Инженерный подход тут состоит в том, чтобы простые вещи писать просто, а сложные — на адекватном уровне сложности.
Код это не произведение исскуства, вся суть кода в том чтобы удовлетворить потребность пользователя, пусть даже низменную. А программисты это всего лишь высокоплачиваемый персонал, который обслуживает потребность пользователя. Пользователь с самыми низменными потребностями куда важней программиста.
Вы слишком принижаете эту профессию, полностью отказываясь от её творческого компонента. Дело ваше, но так делать вовсе не обязательно. Для бизнеса важнее функциональные свойства кода, для программиста — м.б. и эстетические. Тут нужно найти взаимоприемлимый баланс между практичностью и красотой, не ударяясь в крайности. И все будут довольны.Fatik
28.12.2018 13:24Я не говорю про школьника, я говорю про специалиста. По моему опыту, чем опытней специалист, тем проще работать с его кодом. Любую сложную задачу, нао разбивать на подзадачи. И так далее.
Никакого баланса быть не должно, если программист хочет удовлетворять свои эстетические потребности то пусть делает это за свой счет. За счет пользователя, надо удовлетворять потребности пользователя.
i0000
27.12.2018 19:33+1В ИТ делают хорошие вещи, но их процент ничтожно мал. Большинство обслуживает дурацкие потребности, которых раньше просто не существовало, потому что не существовало ИТ. То есть, инженеры не делают великие вещи, инженеры просто поддерживают инфраструктуру перекачки бабла между людьми.
Крайне здравая мысль для эпохи, когда считают, что деньги первичны и вещи сами волшебным образом материализуются из денег («бабло в экономику»)
Хоть один человек понимает сущность денег и самого капитализма, которым принято сегодня безоговорочно восторгаться. А ведь именно он и порождает услуги ради услуг, чтобы главное заработать деньги. И не только в кодерстве, в любой сфере капитализм старается «изобрести потребности, которых не существовало», чтобы «вывыпэ», «бабло в экономику» и все такое, на что фапают капиталисты. А вот созидательный труд и прогрессивные исследования такого гешефта не приносят, поэтому мало интересны «ынвесторам», без которых, по мнению тех же капиталистов, «ыкономика фстанет».s-kozlov
28.12.2018 13:32+2Идите и создавайте свою экономику без денег (читай — без добровольного удобного обмена ценностями), с
блэкджеком и шлюхами«созидательным трудом» и «прогрессивными исследованиями». Только сначала придумайте, кто и по какому принципу будет поставлять вам еду, пока вы занимаетесь этими самыми исследованиями, и кто будет определять, какой труд считать «созидательным» и какие исследования «прогрессивными».i0000
28.12.2018 18:37(читай — без добровольного удобного обмена ценностями)
Я так и читаю, но вот капиталисты зачастую вообще склонны отрицать не только первичность, а и вообще существование «ценностей», будто деньги — это не внедрение зависимости (а они оно самое и есть, выражаясь кодерскими понятиями) между товаром и потребителем, а первичная сущность.
Что для того, чтоб деньги имели смысл, должна быть система, которая бы обеспечивала право на присвоение чужого труда прямо пропорциональное их количеству и поциента. Она есть, но при капитализме поциенты-то хитрые, и решили — а нафига вообще выходить за предел слоя «деньги», можно замыкать их сами в себе, ведь целевая функция — присвоить себе больше оных, а для этого и потребители-то незачем, когда можно делать их из самих себя при помощи законов функционирования финансовой системы, «швабод договора» там всяких…
Но только вот потреблять они все будут реальные ресурсы, а не жевать свои купюры или пластик (которые, кстати, тоже кому-то надо реально произвести). таким образом увеличивая нагрузку на производителей.
Нет, я не против того факта, что в сложной системе с подобным методом разрыва зависимостей сама финансовая система должна производить какой-то отбор мощности на свое существование. Но уровень зарплаты бухгалтера А.И. Корейко в 46 рублей считаю здесь как раз приемлемым вознаграждением, а вот практически легализовавшиеся при капитализме «закрома» оного же деятеля — это необоснованная нагрузка на созидателей.
Если говорить кодерской аналогией, то использовали бы вы, например, какой-нибудь DI контейнер в своем приложении, а он, вместо исполнения своей утилитарной функции и (разумеется) отжирания небольшого ресурса, начал бы вам там биткойны майнить сам в себе, а все ваши приложения бы не получали ресурсов и висли. Выкинули бы вы такой контейнер козе в трещину и написали свой попроще, или вовсе обошлись бы без него, или продолжали бы свято быть уверенным, что контейнер — это первично, и его выкинуть было бы крамольной мыслью, пусть он жрет все больше и больше ресурсов, совершенно неадекватных тому, что требуются на его непосредственные функции, ведь он — основа приложения, а не вспомогательное звено?Vilaine
28.12.2018 21:29Финансовые институты занимают небольшую долю в ВВП и основной положительный эффект от их работы — эффективное распределение ресурсов экономики. Других путей человечеству неизвестно, так что ваше мнение о справедливых зарплатах финансистов (не таких уж больших) никому неинтересно.
0xd34df00d
28.12.2018 22:12Я так и читаю, но вот капиталисты зачастую вообще склонны отрицать не только первичность, а и вообще существование «ценностей»
А есть какие-то объективные ценности?
s-kozlov
29.12.2018 06:45Вода, воздух.
i0000
29.12.2018 10:36А есть какие-то объективные ценности?
Так вроде все вокруг состоит из них. Начиная от табуретки (в случае меня) или офисного кресла (в случае вас), на которых мы вотпрямщас сидим, и электронно-вычислительного компьютера, на котором сейчас пишем. Все эти объективные ценности должны быть произведены и добыты, но почему-то все считают, что они получаются из денег почти что напрямую, а не путем многого числа разноплановых специалистов, которые за эти деньги должны выполнять свою работу. Наверное, потому что лузеры и не смогли освоить курсы «начни зарабатывать уже сегодня».
s-kozlov
29.12.2018 06:50Но уровень зарплаты бухгалтера А.И. Корейко в 46 рублей считаю здесь как раз приемлемым вознаграждением, а вот практически легализовавшиеся при капитализме «закрома» оного же деятеля — это необоснованная нагрузка на созидателей.
То есть зарплата А.И.Корейко (и всех остальных заодно, чего уж там) должна определяться не объективными законами рынка на основе свободного обмена, а решением i0000. Ясно. Спасибо, но мы уже лучше как-нибудь потерпим существование «закромов» А.И.Корейко (которые он у нас не отбирал), чем опять вот этот вот ваш фашизм.
s-kozlov
29.12.2018 06:52использовали бы вы, например, какой-нибудь DI контейнер в своем приложении, а он, вместо исполнения своей утилитарной функции и (разумеется) отжирания небольшого ресурса, начал бы вам там биткойны майнить сам в себе, а все ваши приложения бы не получали ресурсов и висли
Вы таки не поверите, но Spring довольно популярен.
taujavarob
27.12.2018 19:35+1Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.
Раньше? — Это когда?
В середине 70-х прошлого века — когда писали на ЯМБ (язык машин бухгалтерских) печатая программы на телетайпе ЭВМ «Наири-2»?
В конце 70-х прошлого века — когда вызывали «Джина» на БЕСМ-6 чтобы скормить ему программу на Фортране?
В середине 80-х прошлого века — когда запускали колоду перфокарт на PL-1 через устройство ввода перфокарт «EС-ЭВМ»?
В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
В начале 90-х прошлого века — когда переписали всё что было на Foxpro и Clipper?
В середине 90-х прошлого века — когда таскали «мышой на форму» в Дельфи?
В конце 90-х прошлого века — когда «писали классами» Java, от радости как кипятком?
В середине 00-х — когда вовсю использовали Mysql?
В середине 10-х — когда освоили jQuery и страницы веба ожили?
Или в настоящее время — когда все перешли на JavaScript, шуганув оставшихся по нишам?
Год, назовите fillpackart год? (С)
dzsysop
27.12.2018 22:08Я кажется знаю когда, у меня дядя оттуда. Он люто программировал все что под руку попадется (компьютеры типа ZX80, калькуляторы, контроллеры различные, он сделал принтер из маханической печатной машинкив 85 году) и считал и до сих пор считает что программист не программист если он не знает ассемблера. Его время было наверное 70-80ые, так сказать расцвет компьютерной мысли.
Я до сих пор испытываю трепет и уважение перед людьми кто могут писать на ассемблере.
Наверное есть в этом все-таки часть правды. Но с другой стороны скорость разработки несопоставима. То что можно написать на JavaScript за день и то что можно написать на ASM за день — это же как современный телевизор сравнивать с наскальными рисунками, с точки зрения функциональности и пользователя. Для каждого языка и инструманта есть свои задачи.sergeperovsky
27.12.2018 23:32Дело не в ассемблере (ничего особенно сложного там нет), дело в библиотеках. Современное программирование состоит в основном из обращений к библиотекам.
А те времена характеризовались тем, что программист был один на один с ЭВМ. Пустой. Не только среды разработки или компилятора, нет ни одной команды, кроме тех, что напишешь сам. Отсюда и ощущение, что скорость программирования на ассемблере отличается на порядки.dzsysop
28.12.2018 00:20Не хочется долго спорить долго, поскольку и я не готов и возможно правда где-то посередине. Но с ходу у меня есть очень много возражений на безапелляционное:
Современное программирование состоит в основном из обращений к библиотекам.
Да библиотеки очень важны. Но разработка на острие ножа — она как раз менне всего завязана на библиотеки. И самое интересное создается скажем так «создателями библиотек».sergeperovsky
28.12.2018 23:03Транслятор Фортрана заменял каждый оператор вызовом процедуры :)
Попробуйте посмотреть количество инструкций CALL в коде, который пишете «без использования библиотек». Проблема работы на ассемблере была в том, что прежде чем написать CALL, нужно было самому создать процедуру. Поэтому получалось так медленно. Когда речь пошла о создании ассемблерных вставок в код на Паскале ради выигрыша в скорости, трудозатраты оказались совсем не так велики.
sergeperovsky
27.12.2018 23:25Я первый раз столкнулся с подобным текстом 50 лет назад. Тогда появилось структурное программирование и из языков изгоняли GOTO. И программисты доказывали что три варианта цикла и два варианта ветвления слишком мало и есть случаи, когда при помощи GOTO можно сэкономить десяток тактов процессора. И таки выбили себе аварийный выход из цикла и из процедуры. Но в переходах в произвольную точку кода им было решительно отказано.
Это «убило творчество», но резко повысило надежность программ.
Lissov
28.12.2018 13:10В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
Adabas это 70-е а Natural начало 80-х. Мы как раз недавно завершили проект по миграции софта, который работал с начала 80-х на мейнфрейме. Пришлось покопаться в коде на Natural для Adabas. В те времена это было круто, сейчас смотрится ужасно.
Интересен сдвиг восприятия — с одной стороны, в то время софт был написан быстрее и много меньшим количеством людей, чем мы потратили сейчас. С другой — просто реплицировать то, что было сделано тогда, сейчас таки можно сделать гораздо быстрее.
aliksend
27.12.2018 19:54хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности
Мне кажется вы немного путаете понятия сложности самой системы (которая с одной стороны как раз вредит надежности, так как чем больше механизмов в устройстве или кода в программе — тем потенциально больше проблем можем с этим возникнуть) и сложности при разработке и поддержке этой системы. Да, сейчас школьник может написать программу для смартфона по распознавания текста на фотографии, не умея даже собственного сервера и никакого опыта в машинном обучении, просто повторив туториал по какому-нибудь TensorFlow.
Сложнее всего ведь создавать простые вещи, которые будут работать и быть надежными, потому что они простые.
Go или Rust или другие языки связывают руки программисту, не давая выстрелить в ногу, в то время как на C/С++ вы вольны это сделать. Но попробуйте сейчас написать json-парсер или http-сервер на C. Вам точно пригодится высшее образование. На go это сделать проще и благодаря этому мы можем строить бoльшие и более сложные системы, которые будут кроме этого надёжны и просты в поддержке.
Кажется, будто из-за этого профессионала с годами стажа может заменить выпускник университета, но это не совсем так. У профессионала есть опыт, просто раньше это опыт, условно — искать глазами в коде возможные разыменования nil-ов (зачем эти ваши новомодные статические анализаторы, ими только новички пользуются, а я ведь профессионал!), а теперь это опыт другого характера — пусть даже написать на вечер сервис, на который раньше была нужна команда программистов и месяцы работы.
inew-iborn
27.12.2018 20:20вспоминаю свое прошлое…
изучение было с С, потом С++, потом Java…
сейчас в основом Haskell, все хорошо.
Было время когда я почти полгода рефакторил проект, просто пипец был лютейщий… ад.
Пытался привести это в порядок и оставить после себя читаемый код.
Потом я уже писал свой код и вроде доработки после меня шли нормально, ну я надеюсь))
Потом попался код как в первом случае… о боже я тяжело его воспринимал, вспоминая как я легко читал бредятину из первого случая, просто тогда я привык.
Вопрос на засыпку, а писать легко читаемый код это не искусство случаем?Vantela
27.12.2018 20:24+1Неее, это фантастика!(с)
:Dinew-iborn
28.12.2018 08:47то есть, Вы хотите сказать, что нам так и не завезут розовых пони? только дженерики?))) печалька((
mrTyler
27.12.2018 22:41Почему-то после прочтения осталось послевкусие «Автостопом по галлактике» и очень близко промелькнула мысль, что это путь Воганов.
sergeperovsky
27.12.2018 23:48Когда-то все программисты были учеными. Все делалось впервые, не было никаких методик, приходилось изобретать.
Потом появились программисты — инженеры. Они осваивали методики, делали в соответствии с ними инструменты и ими пользовались.
Потом пришли программисты — рабочие. Кодеры пользуются чужими инструментами. Им не известны принципы их работы, но это и не нужно — им достаточно инструкции. И они составляют подавляющую часть программистов.
Ученые и инженеры никуда не делись. И меньше их не стало. Но в общей массе программистов их не видно.
Хотите творчества? Добро пожаловать в разработку уникальных вещей. Прежде всего — нового инструментария. Встали к станку? Не нужно возмущаться, что нужно гнать продукцию по чертежам с точным соблюдением технологии.Vilaine
28.12.2018 08:43+1Потом пришли программисты — рабочие.… Им не известны принципы их работы
Обобщаете? Вероятно, вы хотели сказать "им необязательно знать принципы их работы".
нужно гнать продукцию по чертежам с точным соблюдением технологии
Мало такого в программировании, по-моему. Ни инженеров в стереотипном виде с готовыми метриками и требованиями (кроме узких областей), ни рабочих, выдающих продукцию по чертежам. Какие чертежи при автоматизации бизнес-процессов и прочего? Сначала изучение и анализ области, потом попытка формализации процессов в более менее читаемом виде вкупе с построением работающей системы из доступных составляющих. И это при быстром изменении самого программирования.
Хотя можно рассматривать понятие «инженер» шире (есть даже официальный общеупотребимый термин software engineering), но если не хочется, то необязательно натягивать эти «заводские» рамки на программирование.sergeperovsky
28.12.2018 22:45Вот типичная программа современного вузовского курса по специальности инженер-программист:
1.Основы программирования
2.Алгоритмизация и структурное программирование на C++
3.Разработка реляционных баз данных в MS SQL Server 2012. Язык запросов Transact-SQL
4.UML. Технология программирования и моделирования программных систем
5.Язык программирования Visual C#. Создание .NET Framework приложений
6.Программирование на Java
7.Верстка и разработка web-приложений. Использование PHP и MySQL
8.Механизмы тестирования программного кода
9.Системы построения графического интерфейса
10.Дипломная работа
Теоретических курсов нет вообще.
Есть С++, но нет ни теории формальных грамматик, ни теории алгоритмов, ни комбнаторики, ни теории графов.
Есть SQL, но нет реляционной алгебры.
Что-то раскажут про ООП, но нет теории конечных автоматов.
Сотни часов на обучение конкретным инструментам. Но подсчитать алгоритмическую сложность не умеем.
Я уже не говорю о том, что ни про логическое, ни про функциональное программирование студентам вообще не упомянут.
«Позабудте индукцию и дедукцию — давайте продукцию».
Что же говорить о всевозможных курсах «программист за два месяца».
«Сначала изучение и анализ области, потом попытка формализации процессов в более менее читаемом виде вкупе с построением работающей системы из доступных составляющих.»
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистов. А чаще уже не приходит — удается обойтись подбором и настройкой готовой системы.Vilaine
29.12.2018 02:21Вот типичная программа современного вузовского курса по специальности инженер-программист
Не могу согласиться с вашим резюме по образованию инженера-программиста. У нас было многое базовое из того, что вы полагаете отсутствующим, и кое-что неупомянутое вами, и меньше инструментов (у вас аж 4 языка изучается, неужели такое где-то есть?). Могу согласиться с тем, что в работе требуется намного меньше, чем изучается, и с низким уровнем кадров в постсоветском образовании (некоторые предметы некому вести).
Разработка реляционных баз данных в MS SQL Server 2012. Язык запросов Transact-SQL
Обычно курс разделен на несколько частей. Вот на примере, типичный предмет: на лекциях проходится в каком-нибудь виде реляционная алгебра, на практике какая-нибудь РСУБД.
UML. Технология программирования и моделирования программных систем
Самый близкий к стереотипичной инженерии курс, по-моему, и реже всего используемый в работе до уровня сеньора. Наверно, из-за незрелости индустрии программирования.
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистов
Это часть профессиональных обязанностей инженера-программиста. В очень крупных проектах выделяются аналитики, чья единственная работа — анализ бизнеса, но в своих поддоменах программистам приходится разбираться — аналитики не выдают алгоритмы, они тоже довольно обобщенно описывают среду. Единственное формальное описание процессов — это код. В некрупных проектах программисты зачастую — единственные аналитики, которые разговаривают с бизнесом.
tendium
29.12.2018 11:42У меня все то, о чем вы говорите, было в ВУЗе. И комбинаторика, и теория графов, и теория конечных автоматов. Так что с «типичностью» вашего списка не соглашусь.
arheops
27.12.2018 23:59Тоесть предлагается организовать — что? Ковен магов?
Ну вот выделится какое-то количество некомерческих программистов. Что случится с коммерческими?
Escalibur
28.12.2018 07:11Согласен с товарищем. Только немного структурирую:
1. Высококлассные спецы должны создавать тулзы для построения систем. Их нужно мало и они должны быть очень тщательно спроектированы.
2. А вот пользоваться этими тулзами должны специалисты в предметных областях в декларативном стиле.
То есть позиции кодеров и прочих уборщиц и дворников в айти должны исчезнуть.
Нужно понимать, что ИТ — это инфраструктура цивилизации. И основание её на бизнес интересах до добра не доведёт.
Тут вон идёт сериал про Энгельбарта, где чётко показано, что с 70-80-х годов ИТ поехало совершенно не туда.dyadyaSerezha
28.12.2018 08:09+1Когда я читаю что-то вроде «должны быть» или «должно быть», мне хочется
взяться за револьверржать. Кто будет определять это долженствование и соответствие ему? Кто сказал, что это конекретное «должны» лучше чьего-то другого «должны», где говорится абсолютно обратное? Никто и ничто никому и ничему не должно. Все должен определять свободный рынок, а для стратегических/оборонных областей — госзаказы с открытым и прозрачным конкурсом. Все.Escalibur
28.12.2018 09:25Когда я слышу про свободный рынок, мне хочется в?з?я?т?ь?с?я? ?з?а? ?р?е?в?о?л?ь?в?е?р? ржать. Не смею перечить, но хотелось бы отметить, что почему-то люди предпочитают летать на самолетах и жить в домах, построенных спецами.
Разумеется, никто вам не запрещает строить мазанки не выше трех этажей своими силами. А вот все, что выше, шире, другого назначения — это, извините, не рыночек, а стандарты и требования. И не потому что кто-то идейно против рыночка. А просто потому, что жить хочется.Vilaine
28.12.2018 10:19У вас как у бизнеса всегда остаётся опция нанимать только топовых программистов для разработки очередного офисного пакета или даже какой-нибудь AAA-игры (очень крупные проекты).
От самолетов и домов зависят жизни, в любых таких областях строгая регуляция. Но IT в основном состоит из менее критичных областей. На плохом самолете летать страшно, поэтому я буду платить много за гарантии, а пользоваться забагованным текстовым редактором — нет, за отсутствие багов я много не заплачу. Вполне свободный рынок.
Vilaine
28.12.2018 10:441. Высококлассные спецы должны создавать тулзы для построения систем. Их нужно мало и они должны быть очень тщательно спроектированы.
Любопытно. А в вашем идеальном мире только программисты должны быть высококлассными, или вообще все специалисты? Что остальным делать, кто не стал высококлассным?
2. А вот пользоваться этими тулзами должны специалисты в предметных областях в декларативном стиле.
Нужно понимать, что ИТ — это инфраструктура цивилизации. И основание её на бизнес интересах до добра не доведёт.
В СССР IT было вспомогательным инструментом народного хозяйства, что по сути то же самое, что и интересы бизнеса. Что капиталистический, что социалистический директор будут подпинывать программиста закончить автоматизацию. А на чем базируется IT в вашем мире?
dyadyaSerezha
28.12.2018 08:04+3«чтобы программированием могли заниматься только некоммерческие организации»… «сделал бы порог входа как можно боллее высоким»…
— вот по таким же критериям когда-то жрецы и попы сохраняли письменность и все знания о мире только для себя — не для быдла такие сокровенные и сложные знания! И таки им удалось затормозить развитие человечества на века. ))
Andronas
28.12.2018 10:35Просто иногда надо вытаскивать нос из редактора. Жизнь — это не только программирование.
Adept_Omnissiah
28.12.2018 17:49Идём свергать власть!
Достаём Ленина из саркофага, покупаем броневик…
Короче строим коммунизм!
Ну и я не вижу в этом проблемы. Нормальные, творческие личности всегда востребованы обществом. Если бы их не было, то мы вряд ли бы выбрались из каменного века.taujavarob
28.12.2018 19:36+1Нормальные, творческие личности всегда востребованы обществом.
Это неверно.
Тут много вопросов:
— что такое «нормальные» — это какие? — больше зарабатывающие?
— что такое «творческие личности»? — которые творят что-то новое и неважно что это новое вредно, никому не нужно, никому сейчас не нужно, неизвестно нужно ли вообще, неизвестно нужно ли будет вообще и с какой целью (вредной, нейтральной или критической спасительной?)
— всегда востребованы обществом? — Полно примеров в истории, когда творческий личностей общество гнобило вплоть до сжигании на костре. — Вам наверняка надо изменить тогда ваше определение:
Нормальные, творческие личности всегда востребованы нормальным прогрессивно-мыслящим обществом.
Но тогда вы должны будете определить что есть «нормальное прогрессивно-мыслящее общество» и есть ли это «общество потребления» — то есть общество «капиталистическое»?
Если вы глубоко и рекурсивно помыслите — то вы придёте к необходимости какой-то аксиомы в виде Нормы или Традиции (то есть Веры, она же породит Религию, разговоры о которой гнобимы на Хабре).
Капитализм основан на старой аксиоме — Нельзя закапывать свой талант в землю ибо это грех. (С)
Все остальные рассуждения есть типа «теоремы», стоящие на этой аксиоме.
Однако, как только вы решите "проявить гордыню" и заявить во всеуслышание, что вы сами решаете что делать со своим талантом — закопать его или явить миру? — вы выбиваете эту аксиому из-под ног капитализма и «летите в пропасть» (или вы собираетесь эту аксиому чем-то заменить?)
А деньги? — чем мерить талант? — трудоднями? — почётными грамотами? — разрешением на выезд за границу? — процентом по кредиту? — путёвками в санаторий? — отрезом на костюм? — красными шароварами? — кармой? — лайками?
А нужно ли его мерить? — А как без меры явить его миру? — Ибо явление миру и есть… измерение! — Не так ли?
Что предлагает fillpackart? Он предлагает измерять путём создания нечто типа «закрытой академии программирования»:Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока.
Так поступали ранее (смотри первые Академии) и так поступили однажды… французы (смотри Пантеон куда они помещают ушедшие таланты свои) и так поступили математики (когда их труд отверг как полезный сам Нобель) введя свои премии и медаль.
Но когда уже есть всеобщий измеритель Таланта и это есть сам талант (то бишь деньги), то все эти измерители для сидящих в «высоких башнях из слоновой кости» похоже уже больше не нужны. Поди.
DimaVinipuh
29.12.2018 11:53Вы описали частный случай общей филосовской проблемы: что первично, дух или материя. Все мы имеем стремления, т.е. «души прекрасные порывы», при этом мы отягощены плотью, её необходимостями и, как следствие постоянно идёт взаимная корректировка. Она вечна. Её ещё называют борьбой добра со злом.
dididididi
29.12.2018 13:19+1Читал, что на одном из конкурсов дизайна выиграл рено логан — (первая версия рубленая такая), второе какой-то там ламборджини.
Из объяснения я понял, что он занял первое место, потому что каждая ее деталь штапуются одним ударом дешевого пресса из дешевого металла. В то время как для производства требуется ламбо, нужно очень сильно извращаться, и тогда ко мне пришло понимание, что творчество в простоте.
Знаете, сейчас еще в моде сейчас вручную рисовать фотореалистичные изображение, так вот это не творчество — это онанизм. Творчества и искусство — это двумя штрихами передать все эмоции, а не два месяца вырисовывать какую-то херь, которую можно одним нажатием кнопки сделать.
Втиснуть свой проект в примитивные простые паттерны, который каждый джун поймет, а не городить огород велосипедов на костылях, который можно понять только обладая 20 летним опытом в программировании — это и есть красивый код, а то что вы называете красивым кодом — это мастурбация.
youROCK
Сорян, Бро. Все хотят (ну или когда-то хотели :)), согласен. Но это плохой путь. Разработчики в первую очередь нужны для того, чтобы делать какой-то продукт, который приносит деньги. И чем проще среда, тем продуктивнее будет разработчик (но, как говорил Великий, «Всё следует упрощать до тех пор, пока это возможно, но не более того.»). Чем больше кода можно написать достаточно эффективно и при этом стандартно — тем лучше. Поэтому решения типа Go и появляются — они отвечают современным требованиям серверной («микросервисной») разработки и облегчают написание таких программ. Никого не интересует творчество. Вернее интересует, но это лишь малая часть продукта. В основном нужно просто «прокопать от забора до обеда», и чем меньше усилий для этого нужно затратить, тем лучше, ИМХО.
Neikist
Кстати есть и обратная тенденция. 1с. Исходная идея что все должно быть как можно проще и ближе к предметной области выросла в монстра с кучей разных фич, особенностей и т.п. И продолжает идти в сторону усложнения (пусть и на прикладном уровне, машинное обучение у них в планах, ин мемори субд добавили).
xfaetas
Вообще не совсем понятно, по каким критериям судят о красоте кода: почему красивый код — это обязательно долго и дорого? Может быть подход, при котором получается долго и дорого, не так уж и красив на самом деле.
Lexicon
Забавно, но не то, чтобы сами компании до конца понимали, для чего нужны разработчики.
Вспомним, надавно прошедшую волну статей по собеседованиям, показавшую нам, что требования, взгляды и подход к самому приему на работу не только существенно различаются, но бывают ошибочны и вредны, вне зависимости от размера компании.
Также и с самой разработкой, с критериями оценки производительности.
Лично у меня недавно была ситуация: позвали в проект, существовавший без архитектора, поставили задачу оптимизации. После недельного аудита: готового набора текстов по архитектурным проблемам, гайдов по критическим проблемам команды( а у команды были весьма серьезные проблемы ), заявился владелец бизнеса и усевшись рядом с техдиром поинтересовался. — "а какой вы написали код? вы что, не работали все это время?!".
К огромному сожалению, руководителям часто интереснее, сколько раз вы ударили кувалдой, нежели, то, сколько труда вы приложили для понимания того, куда следует ударить. В долгосрочной перспективе, эти вещи становятся мелочами, но, проработав пару недель — спокойней отписать заявление.
FadeToBlack
Я тоже раньше так думал. Я раньше думал, что творчество заключается в том, что я располагаю символы в нужном порядке, делаю хорошую архитектуру, умные маленькие и быстрые функции, красиво называю переменные (не одной буквой, но и не предложением). В общем, думал, что творчество — это то, о чем говорил автор статьи. Но когда я начинаю рассказывать об этом другим программистам, некоторые из них говорят: «да ну, ты что, правда об этом обо всем думаешь, когда пишешь код?». Я отвечаю, углубляясь в философию и пытаясь привлечь для объяснения аналогии: «Программирование — это управление сложностью. Разрабатывать программу нужно так же, как получать зерна из граната: иногда вместо того, чтобы сосредоточиться на извлечении зерен, нужно сосредоточиться на том, чтобы убрать все лишнее. Так можно не только чистить гранат, но и жить: убрать все лишнее и остаются только ценные зерна, так же можно и программировать — убирать лишний код, чтобы остался только тот, который действительно важен». Но и эти мои мысли не находят поддержки среди программистов. Я пришел в выводу, что все это — психологическое шасси, которое нужно лишь некоторым людям, чтобы обосновать свою деятельность, иметь идейную и философскую поддержку, особенно это важно в моменты, когда ты остаешься один на один с бездной неизвестной сложности, загнанный в угол ограничениями, и связанный обязанностью решить все эти проблемы. И это для меня теперь является творчеством — это когда есть обстоятельства, которые обычно против тебя, а ты пытаешься найти оптимальный выход, адекватный сложившейся ситуации. А пишешь ли ты при этом буквы или нет, хороша ли твоя архитектура… Все это или что-то из этого может иметь ценность или нет в зависимости от обстоятельств, которые в разных проектах и задачах никогда не совпадают.
burfee
Творчество это творчество, а бизнес это бизнес. О чем тут думать ещё. Если нет возможности выбирать, приходится принимать обстоятельства. Только не надо тут же новую философию изобретать. Давайте лучше постепенно с пола вставать на колени, а потом может и ходить научимся.
FadeToBlack
Так я и говорю, что философия в бизнес-разработке неприменима. В отрыве от контекста личности не бывает универсальных принципов, а внутри бизнеса — другие механизмы, подчиняющиеся другим законам логики. Поэтому я перестал беспокоиться об авторском стиле. Я перестал навязывать команде кодестайл, следование стандартам и так далее. Даже архитектура — вещь приходящая и уходящая. Ты просто должен решить, важна в этом месте архитектура или нет. Если это локальная хрень, которую завтра выпилишь или за полчаса перепишешь, или вообще, возьмешь стороннее решение — пусть она лучше будет уродлива, чем тратить на нее время и ресурсы, лучше применить мысль там, где это действительно нужно. Все это не влияет на конечный результат от слова «полностью». А принцип всего лишь один — фигачишь код -> анализируешь результат -> в следующий раз делаешь меньше работы, делая подобную же задачу. Даже не знаю, опять получается, что я постулирую принципы. Но невозможно прочитать их и понять на том уровне, чтобы использовать, надо чтобы они родились в голове каждого конкретного программиста, и у каждого они будут свои.
Simplevolk
Все очень просто: мы переносим сложность из кода в его поддержку и оркестровку: микросервисы->docker->kuber-->?.. Сложность останется. И хорошие программисты станут хорошими devops, оставив писанину скучного кода новичкам.
opencloser
Рано или поздно программист понимает, он не творец, а подмастерье
FadeToBlack
Ничего не мешает ему быть творцом, просто творчество — это не когда ты делаешь что-то гениальное, математически точное, архитектурно красивое и идеальное. Творчество — это когда ты делаешь это так, чтобы другие люди видели в этом все вышесказанное. При этом для тебя это может быть просто квадрат черного цвета.
MeHDeJIeeB
А затем приходит нужда написать что-то сложное типа универсального искусственного интеллекта, который в принципе нереально написать просто и маленькими модулями… И все эти линейные программисты оказываются способными только проедать бюджет инвесторов и создавать ужасные решения на миллионе кастылей, которые не способны к масштабированию и умирают в корчах. А единичные проекты типа kiberis.ru так и остаются уникальными, потому что повторить их слишком дорого и вероятность успеха очень мала. Именно из-за того, что программисты привыкли к простым задачам.
Поэтому ничего с кодом не произойдет. В течение десятка лет появится автоматизация большинства задач линейных программистов, и перед ними станет выбор — либо переходить на новый уровень программирования и создавать сложный код с продуманной архитектурой (что получится мало у кого), либо идти в другие профессии. Потому что просто написание безликого кода станет ненужным.
sumanai
Нет.