Комментарии 356
Программируя, я хочу заниматься творчеством.
Сорян, Бро. Все хотят (ну или когда-то хотели :)), согласен. Но это плохой путь. Разработчики в первую очередь нужны для того, чтобы делать какой-то продукт, который приносит деньги. И чем проще среда, тем продуктивнее будет разработчик (но, как говорил Великий, «Всё следует упрощать до тех пор, пока это возможно, но не более того.»). Чем больше кода можно написать достаточно эффективно и при этом стандартно — тем лучше. Поэтому решения типа Go и появляются — они отвечают современным требованиям серверной («микросервисной») разработки и облегчают написание таких программ. Никого не интересует творчество. Вернее интересует, но это лишь малая часть продукта. В основном нужно просто «прокопать от забора до обеда», и чем меньше усилий для этого нужно затратить, тем лучше, ИМХО.
Кстати есть и обратная тенденция. 1с. Исходная идея что все должно быть как можно проще и ближе к предметной области выросла в монстра с кучей разных фич, особенностей и т.п. И продолжает идти в сторону усложнения (пусть и на прикладном уровне, машинное обучение у них в планах, ин мемори субд добавили).
Вообще не совсем понятно, по каким критериям судят о красоте кода: почему красивый код — это обязательно долго и дорого? Может быть подход, при котором получается долго и дорого, не так уж и красив на самом деле.
Забавно, но не то, чтобы сами компании до конца понимали, для чего нужны разработчики.
Вспомним, надавно прошедшую волну статей по собеседованиям, показавшую нам, что требования, взгляды и подход к самому приему на работу не только существенно различаются, но бывают ошибочны и вредны, вне зависимости от размера компании.
Также и с самой разработкой, с критериями оценки производительности.
Лично у меня недавно была ситуация: позвали в проект, существовавший без архитектора, поставили задачу оптимизации. После недельного аудита: готового набора текстов по архитектурным проблемам, гайдов по критическим проблемам команды( а у команды были весьма серьезные проблемы ), заявился владелец бизнеса и усевшись рядом с техдиром поинтересовался. — "а какой вы написали код? вы что, не работали все это время?!".
К огромному сожалению, руководителям часто интереснее, сколько раз вы ударили кувалдой, нежели, то, сколько труда вы приложили для понимания того, куда следует ударить. В долгосрочной перспективе, эти вещи становятся мелочами, но, проработав пару недель — спокойней отписать заявление.
Я тоже раньше так думал. Я раньше думал, что творчество заключается в том, что я располагаю символы в нужном порядке, делаю хорошую архитектуру, умные маленькие и быстрые функции, красиво называю переменные (не одной буквой, но и не предложением). В общем, думал, что творчество — это то, о чем говорил автор статьи. Но когда я начинаю рассказывать об этом другим программистам, некоторые из них говорят: «да ну, ты что, правда об этом обо всем думаешь, когда пишешь код?». Я отвечаю, углубляясь в философию и пытаясь привлечь для объяснения аналогии: «Программирование — это управление сложностью. Разрабатывать программу нужно так же, как получать зерна из граната: иногда вместо того, чтобы сосредоточиться на извлечении зерен, нужно сосредоточиться на том, чтобы убрать все лишнее. Так можно не только чистить гранат, но и жить: убрать все лишнее и остаются только ценные зерна, так же можно и программировать — убирать лишний код, чтобы остался только тот, который действительно важен». Но и эти мои мысли не находят поддержки среди программистов. Я пришел в выводу, что все это — психологическое шасси, которое нужно лишь некоторым людям, чтобы обосновать свою деятельность, иметь идейную и философскую поддержку, особенно это важно в моменты, когда ты остаешься один на один с бездной неизвестной сложности, загнанный в угол ограничениями, и связанный обязанностью решить все эти проблемы. И это для меня теперь является творчеством — это когда есть обстоятельства, которые обычно против тебя, а ты пытаешься найти оптимальный выход, адекватный сложившейся ситуации. А пишешь ли ты при этом буквы или нет, хороша ли твоя архитектура… Все это или что-то из этого может иметь ценность или нет в зависимости от обстоятельств, которые в разных проектах и задачах никогда не совпадают.
НЛО прилетело и опубликовало эту надпись здесь
Так я и говорю, что философия в бизнес-разработке неприменима. В отрыве от контекста личности не бывает универсальных принципов, а внутри бизнеса — другие механизмы, подчиняющиеся другим законам логики. Поэтому я перестал беспокоиться об авторском стиле. Я перестал навязывать команде кодестайл, следование стандартам и так далее. Даже архитектура — вещь приходящая и уходящая. Ты просто должен решить, важна в этом месте архитектура или нет. Если это локальная хрень, которую завтра выпилишь или за полчаса перепишешь, или вообще, возьмешь стороннее решение — пусть она лучше будет уродлива, чем тратить на нее время и ресурсы, лучше применить мысль там, где это действительно нужно. Все это не влияет на конечный результат от слова «полностью». А принцип всего лишь один — фигачишь код -> анализируешь результат -> в следующий раз делаешь меньше работы, делая подобную же задачу. Даже не знаю, опять получается, что я постулирую принципы. Но невозможно прочитать их и понять на том уровне, чтобы использовать, надо чтобы они родились в голове каждого конкретного программиста, и у каждого они будут свои.
Все очень просто: мы переносим сложность из кода в его поддержку и оркестровку: микросервисы->docker->kuber-->?.. Сложность останется. И хорошие программисты станут хорошими devops, оставив писанину скучного кода новичкам.
Рано или поздно программист понимает, он не творец, а подмастерье
Ничего не мешает ему быть творцом, просто творчество — это не когда ты делаешь что-то гениальное, математически точное, архитектурно красивое и идеальное. Творчество — это когда ты делаешь это так, чтобы другие люди видели в этом все вышесказанное. При этом для тебя это может быть просто квадрат черного цвета.
А затем приходит нужда написать что-то сложное типа универсального искусственного интеллекта, который в принципе нереально написать просто и маленькими модулями… И все эти линейные программисты оказываются способными только проедать бюджет инвесторов и создавать ужасные решения на миллионе кастылей, которые не способны к масштабированию и умирают в корчах. А единичные проекты типа kiberis.ru так и остаются уникальными, потому что повторить их слишком дорого и вероятность успеха очень мала. Именно из-за того, что программисты привыкли к простым задачам.
Поэтому ничего с кодом не произойдет. В течение десятка лет появится автоматизация большинства задач линейных программистов, и перед ними станет выбор — либо переходить на новый уровень программирования и создавать сложный код с продуманной архитектурой (что получится мало у кого), либо идти в другие профессии. Потому что просто написание безликого кода станет ненужным.
Поэтому ничего с кодом не произойдет. В течение десятка лет появится автоматизация большинства задач линейных программистов, и перед ними станет выбор — либо переходить на новый уровень программирования и создавать сложный код с продуманной архитектурой (что получится мало у кого), либо идти в другие профессии. Потому что просто написание безликого кода станет ненужным.
Надо создать профессиональную ассоциацию программеров
неговнокодеров
С уставом и всё-такое
В других специальностях есть подобные институты
Будет, с одной стороны, такой знак качества, а с другой — хранители истинного духа и традиций
Как дети-индиго, только наоборот
неговнокодеров
С уставом и всё-такое
В других специальностях есть подобные институты
Будет, с одной стороны, такой знак качества, а с другой — хранители истинного духа и традиций
Как дети-индиго, только наоборот
Не совсем конечно ассоциация, но есть подобное течение: en.wikipedia.org/wiki/Software_craftsmanship
Создать можно, но не поможет. Замените в тексте статьи программиста на кузнеца, и всё будет так же. Он тут такой, красивый и в белом пальто — делает мир лучше, искусством занимается и тэ дэ, а ему тут нннннннннааа по голове непонятными штуками под названием «стандартизация» и «индустриализация». И как жить, когда кто-то станками клепает взаимозаменяемые детали тысячами, пока ты со всем своим искусством и трогательным отношением делаешь одну?
С кодом всё точно так же. И ниши для штучного программирования и искусства всё равно всегда будут, только вот все в них не влезут.
С кодом всё точно так же. И ниши для штучного программирования и искусства всё равно всегда будут, только вот все в них не влезут.
Вы правы. И как пример можно привести адвокатское и врачебное сообщества в США. Чужих они не пускают. Совершенно неэкономическими методами.
Чужих — это тех, кто не отучился в соответствующих учебных заведениях?
И что в этом хорошего?
Медицина в США — лучшая на планете. Как и юристы.
НЛО прилетело и опубликовало эту надпись здесь
Медицина в США — лучшая на планете
«Я тебе конечно верю, разве могут быть сомненья».
В контексте «лучшей медицины» я еще слышал про Израиль, Испанию, Британию и Канаду. Почему верить я должен именно вам?
А еще даже если вы выработаете критерий «лучшести» медицины и докажете, что она лучшая именно в США, вам также предстоит доказать, что закрытость — это именно причина топового места и медицина лучшая именно благодаря этому, а не вопреки.
Как и юристы.
Собственно все то же самое, просто замените медицину на юриспруденцию.
Некто Robert C. Martin похожему посвятил минимум одну книгу. Получилось максимально уныло, с кучей нравоучений. К сожалению, ее иногда спрашивают ашары.
Надо создать профессиональную ассоциацию программеровсепия-старцы?)
Как дети-индиго, только наоборот
У Go остается свобода в выборе паттернов, алгоритмов и имен переменных. Но многие задачи имеют простое и правильное решение. Это удобно и делает код чище и легче читаемым. Можно зайти в произвольное место стандартной библиотеки, посмотреть как и что написано, без труда понять это и использовать похожий подход. Ничего в этом плохого нет.
Если сравнить с stl от c++ это просто небо и земля. Там хоть и исходники доступны, но понять что же все-таки происходит. Надо как-то понять в каком месте какого шаблонного класса объявлен какой тип и в каком шаблоне он используется и зачем. Вместо объявления интерфейса и требования соблюдения этого интерфейса есть привязка к именам типов и методов и это так усложняет понимание кода, что надо гораздо больше времени чтоб вникнуть. Не говоря уже о том чтобы скопировать увиденный подход к себе в приложение. И вот в чем проблема когда задачу можно решить 15ю способами одна и та же проблема в разных местах приложения будет решена по-разному. Часть из этих решений будет простыми и неправильными. А это уже ведет к разному поведению и такие куски кода может быть тяжело заметить, чтобы свести к общим функциям.
Если сравнить с stl от c++ это просто небо и земля. Там хоть и исходники доступны, но понять что же все-таки происходит. Надо как-то понять в каком месте какого шаблонного класса объявлен какой тип и в каком шаблоне он используется и зачем. Вместо объявления интерфейса и требования соблюдения этого интерфейса есть привязка к именам типов и методов и это так усложняет понимание кода, что надо гораздо больше времени чтоб вникнуть. Не говоря уже о том чтобы скопировать увиденный подход к себе в приложение. И вот в чем проблема когда задачу можно решить 15ю способами одна и та же проблема в разных местах приложения будет решена по-разному. Часть из этих решений будет простыми и неправильными. А это уже ведет к разному поведению и такие куски кода может быть тяжело заметить, чтобы свести к общим функциям.
Очень знакомо и при знакомстве с языком меня сильно удивило. Как-то привык я, что лезть в библиотеки это дело гиблое. Там всегда черт ногу сломит. Проще погуглить решение проблемы, авось кто-то сталкивался. А в Go лезть в код рантайма стало обычным делом, когда мне что-то непонятно или любопытно. Я бы и мог тоже самое сделать с помощью тестового проекта, дебаггера, гугла, стэка, но незачем. Быстрее прочитать и самому все увидеть.
Когда я программировал на C, приходилось заглядывать в код ядра, что бы разобраться в пользовательском приложении.
С тех пор я перешел сначала на Haskell, потом на Scala, и что бы разобраться в библиотеке часто достаточно посмотреть ее интерфейс, даже не документацию. Я этим очень доволен.
С тех пор я перешел сначала на Haskell, потом на Scala, и что бы разобраться в библиотеке часто достаточно посмотреть ее интерфейс, даже не документацию. Я этим очень доволен.
НЛО прилетело и опубликовало эту надпись здесь
C++ и stl создавались в прошлом веке с целью заткнуть текущие дыры в разработке. Не удивительно, что получилось не слишком изящно.
Сравнивать надо не с ними, а с академическими Haskell и SML, и с современным, вобравшим лучшие практики Rust.
Сравнивать надо не с ними, а с академическими Haskell и SML, и с современным, вобравшим лучшие практики Rust.
Ну это вы загнули. Мы в работе используем С++17, который достаточно свеж. :) Сама концепция определения требований у шаблонов хромает. Когда привязка идет не к интерфейсу, а по наличию методов или под-классов с нужными методами. Их нет — получишь ошибку с ссылкой на дебри шаблонной функции где сигнатура не совпала или метод попробовали вызвать. Было бы следование интерфейсам как в Go — сразу получили бы ошибку, мол класс не реализует интерфейс A, надо добавить метод B.
Дизайн унаследован с древних времен, его уже тяжело переделать. Во многом от сюда и сложность поддержки библиотек.
К С++ шаблоны были прикручены сбоку, отсюда и все проблемы. Возьмите язык, где шаблоны были изначально и удивитесь как всё внезапно становится понятно: run.dlang.io/is/vjmZFx
я программирую после работы.
Что программируете? Почему не можете это сделать работой?
Главное, чтобы не вместо.
а что мешает делать и то и то?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вы подменяете желаемое действительным. Можно и нужно смешивать хобби и работу, нужно получать удовольствие от работы, особенно когда работа — большая часть жизни.
Можно и нужно смешивать хобби и работу
особенно когда работа — большая часть жизни
Как раз наоборот. Если работа — большая часть жизни, то тратить что-то от оставшейся части на ту же работу — не лучшее решение. Я бы сказал, что это просто преступно по отношению к себе.
А для того, чтобы получать удовольствие от работы, не обязательно заниматься этой же работой в качестве хобби.
Для начала нужно разобраться, что такое работа. И что такое хобби. И причем тут связь с удовольствием.
Для начала нужно разобраться, что такое работа. И что такое хобби.
Работа — основной источник дохода. Хобби — деятельность, которой человеку нравится заниматься во время, свободное от работы.
И причем тут связь с удовольствием.
Это тема обсуждения в данной ветке, очевидно.
Тогда все становится еще более запутанным. Получается, что вы не хотите, чтобы интересное занятие приносило доход. И не хотите, чтобы нравилось то, чем вы занимаетесь на работе.
Мне не понятна эта связь, учитывая, что эти концепции искусственны сами по себе. Нет в биологическом мире разницы между "работой" и "хобби". Вам не кажется, что вы просто занимаетесь чем-то не тем?
Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаково плохо
Fixed.
Я, как и большинство инженеров, верю, что творю великие вещи.
Такие штуки как docker, kubernetes не достаточно великие вещи? Восхищаются готовым продуктом(nginx, postgresql, mysql и т.д.), а не его исходным кодом.
Похоже у автора просто приступ аллергии к Go.
А вы в курсе, что пришлось сделать команде kubernetes за отсутствием дженериков?
Расскажите. В код залез, но так сходу в таком большом проекте не найдешь что-то.
www.reddit.com/r/golang/comments/7lzbfv/go_experience_report_generics_in_kubernetes
«In short, Kubernetes has built a type naming & identification scheme and a type registry to store each GVK. It took me a long time to identify (pun intended!) this whole thing in the codebase; after I did, I was amazed and impressed.
The core team replaced a compile-time language feature that was missing (Generics) with their home-built runtime system. And given the tools at their disposal, they did a pretty good job.»
Они де-факто форкнули язык Go и сделали себе generics сами. У них своя система типов. работающая в рантайме.
В общем, как правильно говорит Бартош Милевски: «Либо у вас динамическая типизация, либо, рано или поздно, у вас будут generics»
«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»
Забавно, именно эту часть кода я читал, когда полез туда после вашего комментария.
Как правильно сказано в комментариях к той статье, дженерики не имеют к этому никакого отношения и проблему эту решить не могут, они для разных вещей предназначены. И тем более никакого форка не было. Они сделали вполне стандартную вещь — реестр типов. Каждый тип регистрируется руками в реестре. В рантайме какие-то данные по сети сверяются с этим реестром и если тип есть, то сериализуется экземпляр, либо выкидывается ошибка, мол, такого типа в реестре нет. Дженерики, не дженерики — если типа кто-то не написал, то магическим образом он в рантайме не появится. Дженерики, будучи фичей статической типизации, эту задачу не решат. Это пример того, как в язык вкорячили некий вид динамической типизации.
Я в C# тоже что-то подобное делал для сериализация протобуферов и дженерики мне там никак не помогли. Там нужна рефлексия, которая есть и в Go. Еди
Как правильно сказано в комментариях к той статье, дженерики не имеют к этому никакого отношения и проблему эту решить не могут, они для разных вещей предназначены. И тем более никакого форка не было. Они сделали вполне стандартную вещь — реестр типов. Каждый тип регистрируется руками в реестре. В рантайме какие-то данные по сети сверяются с этим реестром и если тип есть, то сериализуется экземпляр, либо выкидывается ошибка, мол, такого типа в реестре нет. Дженерики, не дженерики — если типа кто-то не написал, то магическим образом он в рантайме не появится. Дженерики, будучи фичей статической типизации, эту задачу не решат. Это пример того, как в язык вкорячили некий вид динамической типизации.
Я в C# тоже что-то подобное делал для сериализация протобуферов и дженерики мне там никак не помогли. Там нужна рефлексия, которая есть и в Go. Еди
Мой основной посыл был в том, что многие ссылаются на kubernetes как на успех Go, своего рода флагманский проект, а они сами наткнулись на очень большие грабли с Go и обошли их способом, который, фактически, отрицает саму идею Go. И на самом деле это не флагманский проект Go, который должен доказывать, что Go — серьёзный язык, на котором можно делать почти всё, что угодно, а ровно наоборот: это большой провал Go, который доказывает, что неоPascal с CSP, созданный для решения сугубо внутренних проблем Google не может автоматически быть языком общего назначения. (я так резко отзываюсь, потому что бывший фанат Go)
Перефразируя известную фразу Филиппа Гринспена: "Каждая достаточно сложная программа на Go содержит узкоспециализированную, недокументированную, забагованную и тормознутую реализацию половины CommonLisp"
Рефлексию в Go не рекомендуют использовать без крайней необходимости и неспроста (при этом буквально все используют библиотеки, которые пропитаны ей как бисквит коньяком: encoding/json, gorilla/schema и пр.). Лучше уж нормальная динамическая типизация.
Перефразируя известную фразу Филиппа Гринспена: "Каждая достаточно сложная программа на Go содержит узкоспециализированную, недокументированную, забагованную и тормознутую реализацию половины CommonLisp"
Рефлексию в Go не рекомендуют использовать без крайней необходимости и неспроста (при этом буквально все используют библиотеки, которые пропитаны ей как бисквит коньяком: encoding/json, gorilla/schema и пр.). Лучше уж нормальная динамическая типизация.
Чето у вас каша в голове. Еще раз, это не имеет отношения к языку. На шарпе, яве, го, плюсах. Это решение везде будет одинаковым примерно с разной степенью извращенности реализации. Нигде это не будет красивым. Уж в плюсах точно, где даже рефлексии нет. Это стандартный шаблон, который многими применяется. Так решили разрабы кубера и это их проблемы, а не языка.
В вас и видно, что в вас говорит бывший фанат, который обиделся на что-то. Язык общего назначения был и остался. Кубернетис так и остается отличным примером, что язык применяется и тянет на себе целую индустрию, индустрию контейнеров, т.к. буквально все проекты в ней написаны на Go.
Рефлексию не рекомендуют по другой причине, озадачились бы узнать, прежде чем заявлять что-то. Причина всегда была и есть одна — пакет рефлексий сложен в работе, имеет много подводных камней и неочевидностей, поэтому можно натворить дел. Поэтому не рекомендуют туда лезть всем подряд, а только тем, кто разбирается. Рефлексия сложна по определению. И в стандартной библиотеке он, потому что он нужен и огромное количество библиотек его применяющих лишнее доказательство, что он нужен. По этой же причине рефлексию все пытаются добавить в плюсы.
В вас и видно, что в вас говорит бывший фанат, который обиделся на что-то. Язык общего назначения был и остался. Кубернетис так и остается отличным примером, что язык применяется и тянет на себе целую индустрию, индустрию контейнеров, т.к. буквально все проекты в ней написаны на Go.
Рефлексию не рекомендуют по другой причине, озадачились бы узнать, прежде чем заявлять что-то. Причина всегда была и есть одна — пакет рефлексий сложен в работе, имеет много подводных камней и неочевидностей, поэтому можно натворить дел. Поэтому не рекомендуют туда лезть всем подряд, а только тем, кто разбирается. Рефлексия сложна по определению. И в стандартной библиотеке он, потому что он нужен и огромное количество библиотек его применяющих лишнее доказательство, что он нужен. По этой же причине рефлексию все пытаются добавить в плюсы.
А почему рефлексия в Go есть, хотя она «сложна в работе, имеет много подводных камней и неочевидностей», а обобщённого программирования нет?
Потому что рефлексия это пакет стандартной библиотеки, а обобщенное программирование это глава в спецификации языка. Одно можно просто не использовать и никак это нигде ни на ком не скажется, а другое фундаментальная фича языка, которая наводнит весь код на нем и окажет влияние на каждую строчку кода. Одно требует просто предоставления интерфейса до того, что и так есть в языке. А другое требует очень больших усилий в грамотном дизайне, рассмотрении всех ситуаций, взаимодействия со всеми остальными фичами языка. С последним как раз очень много проблем у всех предложений по дженерикам. Без одного просто невозможно решить многие задачи, а другое практически не требуется на практике (и опыт Go за все эти годы показывает, что дженерики полезны, но не необходимы), а во всех остальных случаях заменяется встроенными обобщенными типами.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
а обобщенное программирование это глава в спецификации языка.
Полиморфизм — он и в Африке полиморфизм. Если человек знает теорию типов, свойства соответствующих систем, их влияние друг на друга — на просмотр и осознание этой главы уйдет порядка нескольких минут. Ну а если он необразован — его проблема.
А другое требует очень больших усилий в грамотном дизайне, рассмотрении всех ситуаций, взаимодействия со всеми остальными фичами языка.
То есть разработчики просто поленились?
Нет, наличие рефлексии затрагивает весь язык. Плохо задизайненый язык или библиотека рефлексии ломают друг друга. Небольшой пример.
НЛО прилетело и опубликовало эту надпись здесь
Надеюсь Geth таким же прорывом Go не считают? А то у меня от этого продукта регулярно болит на работе.
Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
То, что в статье названо "реализацией дженериков", не очень похоже на них. Примеры того, где это используется (опять же, в статье), относятся к сериализации/десериализации объектов. Это чисто ран-тайм операция, дженерики ее не решают.
Без дополнительной аргументации и приведения конкретных примеров лично мне совсем неочевидно, что автор той статьи прав, говоря, что kubernetes пострадали от отсутствия дженериков и реализовали их заменитель.
Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
То, что в статье названо "реализацией дженериков", не очень похоже на них.
Чтобы реализовать генерики, надо патчить компилятор, очевидно. Тут правильнее было сказать не "реализация генериков", а "замена генериков", то есть, при наличии генериков воротить все эти рантайм-забавы бы не пришлось, при этом код был бы более надежен (т.к. фиксировались бы конкретные типы, вместо просто RuntimeObject).
Это чисто ран-тайм операция, дженерики ее не решают.
Дженерики решают то, что после десереализации у вас получится не объект типа Hz4e, а нормальный конкретный тип, с которым вы сможете полноценно работать.
А можете привести пример, как подход, реализованный kubernetes, можно было бы заменить на дженерик для какого-то из имеющихся сценариев использования?
В оригинальной статье этого нет — поэтому выглядит голословно. Но возможно, все так есть, просто автор решил опустить несущественные детали?
Как в любом языке с genericaми?
Десериализация посредством generic методов + рефлексии позволяет на выходе получить результирующий тип, а не его динамическое представление.
Типа var descriptor = getObject().
Десериализация посредством generic методов + рефлексии позволяет на выходе получить результирующий тип, а не его динамическое представление.
Типа var descriptor = getObject().
Извиняюсь, var descirptor = getObject<MyDeployment/>().
- А где тут дженерик?
- Какая из проблем, которые решали создатели kubernetes, решена тут более изящно?
UPD: сорри, не заметил второго коммента :)
В общем, это все здорово, но в принципе мало отличается от вызовов в коде kubernetes. Например, (клик)
kubednsDeployment := &apps.Deployment{}
kuberuntime.DecodeInto(clientsetscheme.Codecs.UniversalDecoder(), deploymentBytes, kubednsDeployment)А еще есть сценарии, где тип, в который надо десериализовать, известен только в рантайме.
Главная сложность — реализация собственно десериализации и поддержка каталога типов, которые в принципе позволяется десериализовывать — никуда не делась (она внутри DecodeInto)
Главная сложность — реализация собственно десериализации и поддержка каталога типов, которые в принципе позволяется десериализовывать — никуда не делась (она внутри DecodeInto)
С генериками каталога никакого не нужно. В том смысле, что его за вас поддерживает сам рантйм языка, без каких-либо затрат со стороны программиста.
Можно посмотреть на репозиторий этого «форка»?
А что великого в докере? Старая проблема, старое решение, посредственные реализация и UX. Просто его выкатила контора на G — вот хомяки и возбудились.
да но нет
Да, полностью согласен с автором… Всё идет именно туда. Вспоминая Фаулера с его «Программистом-фанатиком», нужно тренироваться… дома… А не на работе. И причем именно он по сути и описал ситуацию, рассмотренную автором, перейдя в стан манагеров. Им главное выкинуть в «продакшен». А какой это ценой — баги, недоработки, неэффективный расход времени. Потому и приходит выгорание. Я к чему это все. Везде важна грань. За творчество не всегда можно получить деньги, как и не всегда можно получить деньги за говно-продукт. Нельзя работать ради работы. Также нельзя работать только ради бабла. Времени на прекрасные вещи и на жизнь не останется…
Правильно ли будет тогда программистам устроить не 8-часовой рабочий день, а шестичасовой? Потому что сейчас в некоторых отраслях (геймдев тот же) потогонка такая, что по 14 часов в сутки работают, а в моменты перед релизом могут и больше.
И все равно потом пару лет после релиза допиливают игру то минимально адекватного состояния…
Я вообще за 4 часа бесперерывной продуктивной работы, а потом делай, что хочешь. Как в Греции ;)
НЛО прилетело и опубликовало эту надпись здесь
Только его не повышали 12 лет. Работать 3 дня это не повод для подражания, ИМХО
Если вы на работе не кайфуете, пилите что-то круто и не учитесь, то тогда это плохая работа и тогда понятное дело меньше-лучше.
Если вы на работе не кайфуете, пилите что-то круто и не учитесь, то тогда это плохая работа и тогда понятное дело меньше-лучше.
НЛО прилетело и опубликовало эту надпись здесь
- в гугле такие зп что люди «шикуют» относительно
-
нафиг мне то повышение сдалось?
ну каждый живет как хочет. кто-то хочет уметь дом, машину. а кто-то последние деньги тратит на путешествия.
Если вы смотрели видео то он говорил, что перейдет на фулл-тайм когда нужно будет платить ипотеку или учебы детям.
он «шикует» потому что в Гугле работал. Работал бы на обычную фирму, так бы не «выпендривался» рост зарплаты перестает приносить мотивацию
Деньги покрывают все потребности и смысла их больше зарабатывать нет
у каждого свои потребности. кому-то с любимым/ой и рай в шалаше
Если он для вас пример для подржания, то ради бога. По мне так звучит как мечта бездельника, без обид
А что плохого в том, чтобы работать ради бабла? Я не про гнилую контору, где сидит Федя — гриб, и погоняет Ваней — солдатиком (Федя держит все знания у себя, потому что хочет бабла, Ваня делает дерьмо по той же самой причине, все совпадения случайны). Я про коллектив, где каждый делает свою часть работы за 8 часов, старается быть максимально сосредоточенным и покрыть весь код тестами, чтобы за свою работу не зафакапить, отношения хорошие, менеджеры адекватны и дают нормальные спеки. И вот каждый божий день, приходишь, работаешь и уходишь, а потом получаешь деньги в начале месяца. Да, это не стартап, но в некоторых отделах больших контор есть вполне такое здоровое отношение к жизни.
Во многом согласен с автором. Разработка программ процесс творческий. Всегда надо иметь проект, работа над которым доставляет удовольствие.
Крик души
К сожалению реальность такова, что рынок требует разработчиков, которых нет. В конечном итоге это привело к целой вселенной JavaScript для JavaScript. Этот странный язык повсюду и на клиентской стороне, и на серверной.
Потом и этого стало мало, ведь JS сложен для восприятия и M$ сделала шикарный язык TypeScript. Этот язык в глазах многих разработчиков шикарная дама в корсете, но в моих глазах это безумный шляпник в смирительной рубашке. Ни каких больше фокусов и магии.
Самое же печальное в этой ситуации, что под давлением откровенно слабых разработчиков и их потребностей из мира разработки программного обеспечения вытесняются по настоящему эффективное использование ресурсов, повсюду программы, которые жрут как не в себя. Это про чудо софт написанный на базе электрона, и жирнющие сайты, которые раздувают браузер до мемов про оперативку и хром.
Потом и этого стало мало, ведь JS сложен для восприятия и M$ сделала шикарный язык TypeScript. Этот язык в глазах многих разработчиков шикарная дама в корсете, но в моих глазах это безумный шляпник в смирительной рубашке. Ни каких больше фокусов и магии.
Самое же печальное в этой ситуации, что под давлением откровенно слабых разработчиков и их потребностей из мира разработки программного обеспечения вытесняются по настоящему эффективное использование ресурсов, повсюду программы, которые жрут как не в себя. Это про чудо софт написанный на базе электрона, и жирнющие сайты, которые раздувают браузер до мемов про оперативку и хром.
И ладно бы это давало ускорение разработки. Так нет же. Пишут тонны бойлерплейта, переизобретают одни и те же велосипеды на новом стеке. Меняют дизайн, ещё не закончив менять предыдущий. В результате и разработка медленная, и получающиеся приложения.
под давлением откровенно слабых разработчиков и их потребностей
вытесняются по настоящему эффективное использование ресурсов
Всегда было интересно, почему эти две истории должны противопоставляться? Что мешает сделать эффективное использование ресурсов для откровенно слабых разработчиков?
Что-то повеяло какой-то утопией. Бизнес нанимает разработчиков, чтобы зарабатывать деньги, а не двигать прогресс вперед. Прогресс вперед двигает наука, но и она на службе у бизнеса. Вот когда в основе человеческого общества будет лежать, например, стремление к всестороннему развитию человека, а не к беспорядочному заработку и трате бабла, вот тогда и можно ждать изменений. Корни в этом. А от осинки не родятся апельсинки.
НЛО прилетело и опубликовало эту надпись здесь
В этом занятный парадокс программистов: с одной стороны все такие за творчество-за творчество, которому мешают злобные капиталисты своими глупыми распорядками, лишь бы только сляпать продукт для продажи, фуфуфу, как это низко, а как же полет мысли, а с другой — раз в месяц зарплату вынь да положь.
И возникает резонный вопрос — так ты за творчество или за бабки? Если за творчество — пожалуйста, есть множество open-source проектов, где пригодится творческий порыв. Если за бабки — делай, за что платят и не выступай. Множество же айтишников хотят усидеть на двух стульях: чтобы они, понимаешь, творили, а им за их творчество, соответственно, платили. Это еще можно понять в детском саду, но когда такое на полном серьезе излагают люди 30+, то возникают резонные сомнения в адекватности человека.
И возникает резонный вопрос — так ты за творчество или за бабки? Если за творчество — пожалуйста, есть множество open-source проектов, где пригодится творческий порыв. Если за бабки — делай, за что платят и не выступай. Множество же айтишников хотят усидеть на двух стульях: чтобы они, понимаешь, творили, а им за их творчество, соответственно, платили. Это еще можно понять в детском саду, но когда такое на полном серьезе излагают люди 30+, то возникают резонные сомнения в адекватности человека.
НЛО прилетело и опубликовало эту надпись здесь
Инфантилизм — чума 21 века.
Позволить себе творчество могут только свободные (от проблем удовлетворения бытовых потребностей) люди, коих всегда считанное меньшинство.
Остальные, может, и стремятся к тому, да весьма ограничены в свободе выбора.
Высокооплачеваемый раб(отник) — всё еще раб(отник), потому что жить и творить в свое удовольствие по объективным причинам не может.
Строго говоря, в корне сидит причина не совсем объективная, а точнее «совсем не» — это экзистенциальная неудовлетворенность вследствие несоответствия потребностей возможностям, мелких психотравм, незакрытого гештальта и общей недозрелости личности (привет, инфантилизм из из первого абзаца).
Позволить себе творчество могут только свободные (от проблем удовлетворения бытовых потребностей) люди, коих всегда считанное меньшинство.
Остальные, может, и стремятся к тому, да весьма ограничены в свободе выбора.
Высокооплачеваемый раб(отник) — всё еще раб(отник), потому что жить и творить в свое удовольствие по объективным причинам не может.
Строго говоря, в корне сидит причина не совсем объективная, а точнее «совсем не» — это экзистенциальная неудовлетворенность вследствие несоответствия потребностей возможностям, мелких психотравм, незакрытого гештальта и общей недозрелости личности (привет, инфантилизм из из первого абзаца).
По моему опыту «творчество» и «бизнес» противопоставляют не самые лучшие разрабы, у которых «творчество» — это одно из двух:
— бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
— бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова
Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.
А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.
— бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
— бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова
Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.
А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.
НЛО прилетело и опубликовало эту надпись здесь
медицина, погода, ракетостроение, астрономия, прикладная физика/химия
Без знаний в предметной области чистый программист там будет работать в лучшем случае в статусе code monkey: «закодь-ка мне эту формулу, чтобы строился вот такой график вот этим цветом».
У возможно, это будет самое полезное, что сделает программист в своей рабочей жизни =D
Так ведь программист вне контекста предметной области — это разве что «тыжпрограммист». Что вообще общего у одного программиста и другого? Работа с логическими устройствами. А какого рода работа? Вполне конкретная — перевод команд с человеческого языка на язык логики устройства. Можно ли работать профессиональным переводчиком с английского на китайский, не зная оба языка, культуру и особенности?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов.
Я примерно так отвечал когда люди говорили что хаскел сложный — сложность инструмента должна соответствовать сложности задач, как у Стаффорда Бира — сложность системы управления должна соответствовать сложности объекта управления.
Был один «простой» язык — PHP, да вот оказалось что он годиться только для простых задач, а когда его начали применять в чуть более сложных, он превратился в джаву и потерял смысл.
НЛО прилетело и опубликовало эту надпись здесь
Вот не факт — если ты уже освоил полноценный инструмент, то зачем использовать убогий?
Если ты уже умеешь гит, разве станешь юзать cvs в том проекте где его достаточно?
Если ты уже умеешь гит, разве станешь юзать cvs в том проекте где его достаточно?
Я думаю тут играет эффект еще то, что на js что-то простенькое проще написать.
Это как писать телеграм ботов на go — то, что делается за неделю, программист на питоне делает за день, просто в силу того, что питон выразительнее. А производительность тут не особо играет роль.
Это как писать телеграм ботов на go — то, что делается за неделю, программист на питоне делает за день, просто в силу того, что питон выразительнее. А производительность тут не особо играет роль.
Да, допускаю, что для каких-то прототипов, скриптов, питон может остаться, в принципе я выделяю три языковых ниши: системное программирование (Rust), прикладное с упором на надёжность/производительность (Haskell) и прикладное с упором на скорость разработки/сопровождаемость (Python).
Понятно, что любые категории это упрощение, но мне сейчас видится так. Хотя, если условный хаскел попадёт в образование и станет мэйнстримом, а значит привычным для большиснтва разработчиков, то может оказаться, что ниша условного питона очень мала.
Понятно, что любые категории это упрощение, но мне сейчас видится так. Хотя, если условный хаскел попадёт в образование и станет мэйнстримом, а значит привычным для большиснтва разработчиков, то может оказаться, что ниша условного питона очень мала.
Я довольно мало знаю о хаскелле, так что мне тут нечего сказать, но основная фишка питона в плане написания чего-то не очень нагруженного связана с тем, что на нем вы пишите исключительно логику, избегая всяких связываний и бойлерплейтов.
То есть вплоть до того, что когда вам нужно написать какую-то консольную тулзу, вы просто пишите питоновскую функцию, добавляете библиотеку и она сама автоматически превращается в консольную команду.
То есть вплоть до того, что когда вам нужно написать какую-то консольную тулзу, вы просто пишите питоновскую функцию, добавляете библиотеку и она сама автоматически превращается в консольную команду.
НЛО прилетело и опубликовало эту надпись здесь
При этом сам JS притащили уже везде где только можно.
По поводу творчества
В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов. Ничего не поменяется. Лично я не считаю, что это плохо. Конечно, растёт доля некачественных продуктов, но и количество хорошего ПО увеличивается. Можно сравнить эту ситуацию с элитарной и массовой культурой, плюсы и минусы есть и там, и там. Каждый решает сам, что ему ближе.
По поводу "элитарного клуба" программистов
И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока
Ваша цель – это сложность ради сложности. Чем сложнее процесс написания и чтения кода – тем лучше. Единственный смысл такого занятия – тешить своё самолюбие.
Также сразу встаёт вопрос, на что вы будете, например, жить, ведь ничего полезного для обычных людей вы делать не собираетесь. А значит и денег это занятие приносить не будет. На одном же энтузиазме далеко не уедешь.
[шутуа]
Представим себе своего рода Шаолинь: монастырь программистов — монахов. Живут на подаяния, оттачивая искусство программирования.
Ездят с лекциями. Дают платные уроки программирования.
И даже можно придумать им сверхзадачу.
Например они — последняя надежда человечества перед лицом опасности прявления злобного ИИ.
Они должны суметь с ним совладать во время великой битвы интеллектов :)
Представим себе своего рода Шаолинь: монастырь программистов — монахов. Живут на подаяния, оттачивая искусство программирования.
Ездят с лекциями. Дают платные уроки программирования.
И даже можно придумать им сверхзадачу.
Например они — последняя надежда человечества перед лицом опасности прявления злобного ИИ.
Они должны суметь с ним совладать во время великой битвы интеллектов :)
В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов
Только вот книги или фильмы почти всегда — самоцель, конечный продукт. А код является самоцелью только в книжках Кнута. Но в иных случаях он всегда вторичен по отношению к задаче. Никому он неинтересен в отрыве от неё. То есть логически не получается (по крайней мере в том же ракурсе)
Каждый решает сам, что ему ближе.То есть если в кино абстрактная красота может иметь ценность без обоснования, то в коде только в контексте решаемой задачи (как это лучше поможет её решить).
А вот тут интересная заковыка получается. Если отойти немного от темы и оглянуться вокруг, то мы увидим философию с диалектикой Гегеля и синергетику, которые пытаются понять как развиваются системы. И вот они как раз почему то констатируют что все развивается от простого сложному. Просто есть условно говоря «плохая» сложность, которая всем мешает, и «хорошая» сложность, которая служит фунадентом, для построения систем нового порядка. Переход от вычислений на бумаге и счетах к компьютерам тоже ж по своей сути был увеличением сложности, но… на нем выросли целые отрасли, поменялись экономические модели и социальные отношения. Все стало проще? Отнюдь. Увеличение сложности еще не значит что это плохо.
Автор естественно хочет себя реализовать. Хочет оставить какой-то след, который будет жить самостоятельной жизнью и иметь черты автора, что понятно. Это важная потребность человека. Корпоративное программирование это совсем не то место, где это случается. Хотя по началу кажется, что это именно то самое место. А нет. Если автор хочет себя реализовать в программировании, он должен делать что-типа Skype-а, каким он был во время своего появления; какое-то уникальное очень полезное ПО. И скорее всего свое.
Часто девиз бизнеса — безобразно, но единообразно. Но основное противоречие в том, что автор пытается реализовать себя в «работе на дядю». Дядя лучше знает, что ему нужно. И готов подавлять позывы рабочих к самореализации требованиями и деньгами. Дядя реализовывает себя.
Но кое-что может остаться кроме денег. Это квалификация, которую могут оценить другие и которая может открыть новые возможности. Если же и этого не остается, то из такого места надо точно бежать, если там не платят 100тысячмиллионов, использую которые можно себя реализовать или потом или в свои проектах.
Часто девиз бизнеса — безобразно, но единообразно. Но основное противоречие в том, что автор пытается реализовать себя в «работе на дядю». Дядя лучше знает, что ему нужно. И готов подавлять позывы рабочих к самореализации требованиями и деньгами. Дядя реализовывает себя.
Но кое-что может остаться кроме денег. Это квалификация, которую могут оценить другие и которая может открыть новые возможности. Если же и этого не остается, то из такого места надо точно бежать, если там не платят 100тысячмиллионов, использую которые можно себя реализовать или потом или в свои проектах.
Да, да и еще раз да.
Пришел к подобным выводам 7 лет назад и ушел в сисадмины. Сисадмин может себе позволить программировать для себя.
Так что теперь программирование это или скрипты для работы или хобби. Вот сейчас решил джаву вспомнить.
PS Ну, ладно. И за большими деньгами ушел. Тоже. ;-)
Пришел к подобным выводам 7 лет назад и ушел в сисадмины. Сисадмин может себе позволить программировать для себя.
Так что теперь программирование это или скрипты для работы или хобби. Вот сейчас решил джаву вспомнить.
PS Ну, ладно. И за большими деньгами ушел. Тоже. ;-)
От созидания в эксплуатацию?)
И где это у админов большие деньги? В среднем меньше чем у кодеров
У САПеров больше. И в среднем и в частном.
В том то и дело. Текущее программирование уже как бы и не созидание.
Как бы кратко сформулировать то.
Есть правила как назвать переменные, как назвать функции. Как построить работу модуля\программы\чего угодно. Есть правила для внешних интерфейсов для внутренних. Правила для всего. Делать какое то изящно-красивое решение — нельзя. Мало того что оно как правило больше времени займет, так и не поймет потом никто. Поэтому только самое простое, только в лоб.
Если вы пишете проект командой, то код который вы должны написать, он как бы уже виртуально написан. Просто вы его должны напечатать.
И самое ужасное — я отлично понимаю, что так и должно быть. Что все эти правила обеспечивают и понимание другими людьми моего кода, и мое понимание чужого, и я через год благодаря этим правилам пойму что сам же написал. И меньше ошибок будет и прочее прочее.
Кратко не получилось.
В том то и дело. Текущее программирование уже как бы и не созидание.
Как бы кратко сформулировать то.
Есть правила как назвать переменные, как назвать функции. Как построить работу модуля\программы\чего угодно. Есть правила для внешних интерфейсов для внутренних. Правила для всего. Делать какое то изящно-красивое решение — нельзя. Мало того что оно как правило больше времени займет, так и не поймет потом никто. Поэтому только самое простое, только в лоб.
Если вы пишете проект командой, то код который вы должны написать, он как бы уже виртуально написан. Просто вы его должны напечатать.
И самое ужасное — я отлично понимаю, что так и должно быть. Что все эти правила обеспечивают и понимание другими людьми моего кода, и мое понимание чужого, и я через год благодаря этим правилам пойму что сам же написал. И меньше ошибок будет и прочее прочее.
Кратко не получилось.
Тяжело не согласиться. Но это так только в прикладном программировании, а оно не одно в индустрии.
Про "виртуально" написанный код. Ну так виртуально много чего существует, просто мы еще этого не знаем. Почему и корректен именно термин "открытие" в науке. Все примеры решены, гипотезы доказаны. Это весь мир так устроен
Это вам не роман, какой к чёрту авторский стиль?!
Именно. Программист — инженер, а не писатель, вы реализуете спецификацию. Ваш код должен быть безликим, чтобы человек, который будет работать с вами просто вносил необходимые изменения, не тратя время на осознание вашего 'авторского стиля'.
Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар. Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже».
Напомню, что код пишется для людей. Если кроме вас его никто не может понять, то бизнес зависит от того, как успешно вы уворачиваетесь от автобусов. Завтра вы написали заявление по собственному — код можно выкидывать.
Впрочем, вы сами написали это ниже:
возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом. Так компании будет намного комфортнее
Не можете написать просто и эффективно — страдайте.
Они не добавили дженерики в Go, потому что дженерики — сложные.
- В Go 2 дженерики будут
- Те, кто хотел, использовали кодогенраторы.
- Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.
- C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
Я так понял автора, что он делал упор не на то, что код должен быть витиеватым, а на том, что оптимальность и стиль конечного продукта неважен в современном бабломире.
Я лично за единую архитектуру проектов в рамках конкретного бизнес-решения (мне нравится DDD).
Я лично за единую архитектуру проектов в рамках конкретного бизнес-решения (мне нравится DDD).
Именно. Программист — инженер, а не писатель
Мне ближе метафора «строитель», она нагляднее.
В Go 2 дженерики будут
Вот когда будут, тогда и поговорим.
И вероятность их появления все еще небольшая. Дженерики все еще слишком сложные и их ценность это не оправдывает.
Подскажите, а сложные для кого?
Для программистов? Мне кажется, концепция программирования с каналами и горутинами, которая используется в go куда сложнее, чем "ой, мы можем параметризировать типы".
Для разработчиков языка? Очень грустно, учитывая, что все остальные языки довольно легко это освоили.
Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.
А вы точно знаете, что такое дженерики и зачем они нужны? И как бы, зачем вы требуете их в питоне?
Ну и алсо, в питоне есть дженерики, как только там ввели подсказки по типам.
C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
И сколько из-за этого боли испытывают java программисты, вы не представляете. И даже есть очень долгоиграющий проект, который пытается это пофиксить, но все никак.
А вы точно знаете, что такое дженерики и зачем они нужны?
Я пишу на шарпе и не пишу на Go.
Ну и алсо, в питоне есть дженерики, как только там ввели подсказки по типам.
Они не энфорсятся интерпретатором — их по сути(т.е. они даже видны в рантайме, чем пользуются некоторые DI-фреймворки, но это скорее сайд-эффект) нет, если не учитывать сторонние линтеры.
И как бы, зачем вы требуете их в питоне?
Их и не может быть в питоне в чистом виде — нет нормальных типов => нет дженериков. На питоне делают руками то, что реализует компилятор и рантайм в том же C# и добиваются успеха, выдавая сложный и рабочий код — точно так же смогут и в Go.
Собственно, по этой причине я не согласен с автором.
Неизмеримое количество нетривиального и полезного софта написано вообще на сях, без дженериков(да, есть макросы, но всё же), вывода типов, исключений, чего угодно — посредственные разработчики просто бы просто не вытянули такие проекты. Опенсорсного, кстати — это не какой-то большой дядька решил, что они сэкономят бюджет, а выбрали сами девелоперы.
На F# же, который автор поставил в теги и, скорее всего, считает хорошим языком, я слышал только о FAKE, который не то, чтобы сильно популярен или не имел аналогов.
Где все те гениальные проекты, которым мешает простота языка и грязные решения? А нет их, не подтверждает реальность слова автора.
Их и не может быть в питоне в чистом виде — нет нормальных типов => нет дженериков. На питоне делают руками то, что реализует компилятор и рантайм в том же C# и добиваются успеха, выдавая сложный и рабочий код — точно так же смогут и в Go.
Эм… что? То есть помимо того, что нормальные типы то у нас есть, у нас строгая типизация, все-таки, в питоне вы не делаете это ручками. У вас просто нет типа у переменной (потому что типизация динамическая), а следовательно нет нужны в дженериках, потому что у вас все работает как-будто под дженериками.
Грубо говоря, если на C# без дженериков вы бы писали как-то так (псевдокод):
Array x = new Array();
int a = 5;
x.add(a);
assert a == castToInt(x[0])То в питоне приведение типов вам не нужно, потому что при добавлении в список тип переменной не затирается.
Эм… что?
То есть помимо того, что нормальные типы то у нас есть, у нас строгая типизация, все-таки
в питоне вы не делаете это ручками.
Вы делаете:
- Обеспечиваете типобезопасность.
- Реализуете менее очевидные вещи, которые достаются с дженериками. В 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();Т.е имея информацию о типе для дженерика создавать инстансы объектов. Всё это можно сделать в питоне, но придётся в явном виде передавать типы и интерпретатор даже не ругнётся, если где-то типы окажутся несовместимы / код упадёт где-то дальше.
Почти все, что вы написали в целом относится к вопросу «динамическая или статическая типизация» на мой взгляд.
Ну, исключая тот факт, что в питоне вам не нужно передавать тип, вы можете просто достать тип из объекта.
Ну, исключая тот факт, что в питоне вам не нужно передавать тип, вы можете просто достать тип из объекта.
>В java так нельзя из-за type erasure
Вообще-то можно. Типы полностью никуда не исчезают, они всегда в рантайме были, хотя не везде, да и достать их не всегда просто. Гуглите например guava typetoken.
Вообще-то можно. Типы полностью никуда не исчезают, они всегда в рантайме были, хотя не везде, да и достать их не всегда просто. Гуглите например guava typetoken.
C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?
Проблема (была?) с дженериками в Go в том, что дизайнеры говорят, что это зло, а не то, что: «ребята, блин, неуспели, скоро допилим, ждите»
Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода
Карл, зачем в динамических языках дженерики?
С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?
Я не говорю, что это повод для подражания. Я утверждаю, что отсутствие дженериков(и любых других фич языка) только усложняет работу, заставляя писать больше кода, но точно не стирает границу между сильными разработчиками и слабыми, как утверждает автор.
Не понимаю, что плохого в простом коде? Простота — это красота. Программа должна быть логичной, как «Начала» Евклида. Не испытываю симпатии к «сумрачным гениям», которые вместо того, чтобы сделать нормально, начинают изобретать какие-то только им понятные подходы.
Простота — это красота.
Это абсолютно верно. Проблема начинается, когда упрощение работает против выразительности и безопасности. К тому же язык программирования чем-то схож с языком естественным, на нем тоже человек выражает какие-то свои мысли. И если тебе всё время нужно говорить про «снег», то хотя бы одно слово для этого нужно вместо «то, что холодное, белое и падает с неба». Это я к тому, что упрощение хорошо только до некоторого предела, гоу на мой взгляд эту грань перешел.
Проблема известная — ремесло vs творчество. В ремесле как правило деньги, в творчестве как правило свобода. Сочетание денег и свободы можно поискать в стартапе, но обычно такое длится не более полугода. Дальше либо начинается ремесло, либо инвестор перестает спонсировать «творцов».
>> Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока.
GitHub / open source, или это не то?
GitHub / open source, или это не то?
Не могу согласиться с автором по нескольким причинам.
Во-первых неправильные вводные:
Возможно автор забыл что на земле всего 7.5 млрд человек. Из них примерно 50% нетрудоспособное население. Остается всего давайте скажем 3.5 млрд. «сотни миллионов» предполагают хотя бы «2 сотни млн». То есть Двести Миллионов программистов. Вы уж извините, но мои оценки намного скромее, дай бог если на планете есть 10 млн ИТшников.
Примерно такая же попытка обобщать на некотором количества личного опыта. В программировании, как и в практически любой отрасли, есть «гении» и рабочие пчелы. Да пчел больше. Но никто не отменял и не мешает автору или любому из нас стать «гением». Именно они меняют индустрию год за годом. Именно они пишут новые языки программирования и изобретают новые концепты. И уже рабочие пчелы либо принимают предложенныеконцепты либо отвергают их.
Это относится далеко не ко всем «пчелам» и совсем не относится к «гениям».
Это не новое время. Так было всегда. Сделать мало — надо еще донести продукт до потребителя, обосновать справедливость цены, продемонстрировать удобство для пользователя, доказать что «хорошо сделано» и в общем случае что цега-качество как минимум не хуже чем у конкуренттов. Все это основы торговли и экономики и так было всегда с момента изобретения денег и появления хоть какой-либо альтернативы и конкуренции.
Это уже как я сказал сделано, просто не так радикально. Когда гиганты индустрии работают над новыми чипами, языками, системами, протоколами, они не ограничены только потребностями бизнеса, они делают что-то просто потому что они верят что это хороший продукт. Да иногда они бросают какие-то не «выгоревшие» продукты и проекты.
Но если вы имеете в виду радикально не разрешать бизнесу программировать. Это нео-цифровой-тоталитаризм? Вы хотите продавать или давать свой код бесплатно только тем кто «заслужил»? и только в «квадратной» упаковке? вы серьезно? У меня теряется дар речи от такого предложения.
Я понимаю что у вас лично что-то там наболело. И у вас возникли какие-то мысли по какому-то поводу. Но ни вводные данные не вызывают особого доверия и не выдерживают критики. Ни ваши выводы не вызывают во мне ни симпатии ни поддержки. В некоторых предложениях я вижу нить рассуждений, но это проблески здравого смысла, которые никак не связываются ни с вводными данными ни с выводами, которые вы делаете.
Моя позиция состоит в том, что есть области где любые нестандартные и творческие решения очень даже приветствуются. Если вам надоело быть «машиной» для программирования, просто поищите другие проекты — их много. Достаточно много.
Просто вы можете обнаружить что там уже довольно высокий порог входа. Что все о чем вы «мечтали» уже есть.
Или начните свой проект. Напишите свой язык программирования. Не забывайте что Linux был создан студентом. А PHP был по сути полускриптом для личного пользования. У вас есть что-то что отражает ваши «творческие» порывы в программировании? просто доведите это до какого-то состояния и положите на гитхаб. Вы очень удивитесь насколько это может оказаться интересным окружающим.
Я не согласен с Вами и Вашими выводами. На мой взгляд, индустрия делает отсев ненужного в автоматическом режиме и делает это хорошо. Места для творчества много просто не надо искать его в поддержке сайтов на WordPress или в пресловутом 1С. Если ваш последний опыт не очень вас удовлетворяет — не делайте выводов об индустрии и бизнесе. Просто сформулируйте что именно вам хотелось бы делать и ищите подходящий проект, поверьте выбор огромен и возможно где-то сейчас ищут именно Вас!
Во-первых неправильные вводные:
в гигантскую индустрию, где работают сотни миллионов людей.
Возможно автор забыл что на земле всего 7.5 млрд человек. Из них примерно 50% нетрудоспособное население. Остается всего давайте скажем 3.5 млрд. «сотни миллионов» предполагают хотя бы «2 сотни млн». То есть Двести Миллионов программистов. Вы уж извините, но мои оценки намного скромее, дай бог если на планете есть 10 млн ИТшников.
Но мне говорят — супер решение не нужно. Нужно обычное.
Примерно такая же попытка обобщать на некотором количества личного опыта. В программировании, как и в практически любой отрасли, есть «гении» и рабочие пчелы. Да пчел больше. Но никто не отменял и не мешает автору или любому из нас стать «гением». Именно они меняют индустрию год за годом. Именно они пишут новые языки программирования и изобретают новые концепты. И уже рабочие пчелы либо принимают предложенныеконцепты либо отвергают их.
Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом.
Это относится далеко не ко всем «пчелам» и совсем не относится к «гениям».
А мы сейчас живем в то время, когда «хорошо сделанное» и «прибыльное» — разные вещи.
Это не новое время. Так было всегда. Сделать мало — надо еще донести продукт до потребителя, обосновать справедливость цены, продемонстрировать удобство для пользователя, доказать что «хорошо сделано» и в общем случае что цега-качество как минимум не хуже чем у конкуренттов. Все это основы торговли и экономики и так было всегда с момента изобретения денег и появления хоть какой-либо альтернативы и конкуренции.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Это уже как я сказал сделано, просто не так радикально. Когда гиганты индустрии работают над новыми чипами, языками, системами, протоколами, они не ограничены только потребностями бизнеса, они делают что-то просто потому что они верят что это хороший продукт. Да иногда они бросают какие-то не «выгоревшие» продукты и проекты.
Но если вы имеете в виду радикально не разрешать бизнесу программировать. Это нео-цифровой-тоталитаризм? Вы хотите продавать или давать свой код бесплатно только тем кто «заслужил»? и только в «квадратной» упаковке? вы серьезно? У меня теряется дар речи от такого предложения.
Я понимаю что у вас лично что-то там наболело. И у вас возникли какие-то мысли по какому-то поводу. Но ни вводные данные не вызывают особого доверия и не выдерживают критики. Ни ваши выводы не вызывают во мне ни симпатии ни поддержки. В некоторых предложениях я вижу нить рассуждений, но это проблески здравого смысла, которые никак не связываются ни с вводными данными ни с выводами, которые вы делаете.
Моя позиция состоит в том, что есть области где любые нестандартные и творческие решения очень даже приветствуются. Если вам надоело быть «машиной» для программирования, просто поищите другие проекты — их много. Достаточно много.
Просто вы можете обнаружить что там уже довольно высокий порог входа. Что все о чем вы «мечтали» уже есть.
Или начните свой проект. Напишите свой язык программирования. Не забывайте что Linux был создан студентом. А PHP был по сути полускриптом для личного пользования. У вас есть что-то что отражает ваши «творческие» порывы в программировании? просто доведите это до какого-то состояния и положите на гитхаб. Вы очень удивитесь насколько это может оказаться интересным окружающим.
Я не согласен с Вами и Вашими выводами. На мой взгляд, индустрия делает отсев ненужного в автоматическом режиме и делает это хорошо. Места для творчества много просто не надо искать его в поддержке сайтов на WordPress или в пресловутом 1С. Если ваш последний опыт не очень вас удовлетворяет — не делайте выводов об индустрии и бизнесе. Просто сформулируйте что именно вам хотелось бы делать и ищите подходящий проект, поверьте выбор огромен и возможно где-то сейчас ищут именно Вас!
Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.
Например, проблему отсутствия generic'ов — одинаковым копипастом. Хотя постойте, некоторые (судя по комменту выше) используют кодогенераторы.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.
Каким образом будет финансироваться программирование ради программирования?
Программируя, я хочу заниматься творчеством. Хочу иметь огромное число опций, когда дизайню систему. Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение.
Имхо, творчество заключается не в расстановке пробелов, а в создаваемых фичах. Для творчества всё равно остаётся огромное пространство — какие фичи реализовать и как.
Вместе с моделированием реальности программные системы моделируют и сущности, не имеющие к реальности отношения — примеры есть среди паттернов программирования. От творчества, от выбора способа, каким образом реализовать фичу, по-прежнему не уйти.
А пробелы и табы — это не так важно, как фичи.
Например, проблему отсутствия generic'ов — одинаковым копипастом.
А для многих других проблемы такой нет и вовсе. go generate так вообще ниразу не трогал. В это людям обычно сложно поверить, особенно живущих только в мире сложных и больших языков, но встроенных дженерик массивов и словарей достаточно практически для всего. Я дженерики конечно жду в Go 2, но мне лично все равно, будут ли они или нет. Есть куда более важные вещи, которые стоит сделать в новой версии. И если дженерики надо принести в жертву ради этого, то будут только за. Потому как Go 2 хоть и делают, но раздувать спецификацию до размеров плюсов никто не собирается. Будет добавлена пара тройках больших фич.
И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов. Типа, давайте на каждую задачу будет одно правильное решение. Но это же обман!
Смысл того, зачем Go отрезал от себя намеренно как больше частей, это получить небольшое число фич, но которые идеально совмещаются и все ортогональны друг другу. Нет ничего хуже, чем новая фича в языке, которую надо гвоздями прибивать к другим конструкциям, потому что кто-то не думал обо всех вариантах ее приминения. Это имеет далеко идущие последствия, когда библиотеки находятся в постоянном подвешенном состоянии и экосистема так и не сходится на чем-то одном. За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.
В конечном итоге, Go это всего лишь язык. Никого он ничем не ограничивает там, где это действительно имеет значение. Он позволяет написать абсолютно все что угодно бесчисленным числом способов.
Go — это бизнес-эффект, а не инженерное решение
Как раз таки это инженерное решение от и до. Его придумали инженеры для инженеров и они же его выбирают. Не бизнес нахайпил Go до сегодняшнего уровня, а программисты, которые на выходных побаловались и агитировали остальных перелезть на него. Таких историй туча и всегда инициатива исходит от инженеров.
Вот я программист, бизнес мне нафиг не сдался, я код пишу и творю. Мне не нужен язык с десятком вариантов сделать одно и тоже. Это пройденный для меня этап становления как программиста. Go один из немногих языков, который приносит удовольствие. Я писал и продолжаю писать на разных языках, но он вот такой единственный. И при любой возможности я пытаюсь писать новый проект именно на нем. Я не только удовольствие получаю, так я еще заодно получаю все преимущества его экосистемы. Я ничем не жертвую даже.
Продолжать можно долго, но почти во всем у вас наблюдается явное непонимание зачем это все сделано. Весь пост пропитан какой-то джуниорской наивностью. Иначе вас бы не удивляло требование переписать слишком сложный сервис, пусть чуть медленнее. Это очевидная вещь.
За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.А можно примеры? Ну кроме стандартной проблемы вызова асинхронного кода из синхронного. А то как-то ни разу в моей практике реальных проблем не было.
Ищите позиции исследователя (research engineer), и у вас будет определённая свобода. Говорю по собственному опыту.
А так все верно, и про творчество, и про безликость.
А так все верно, и про творчество, и про безликость.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.
Мне кажется, то что вы предлагаете, хорошо находит свое отражение в OpenSource. В котором бизнес не ставит ограничения по срокам. В тоже время, в OpenSource, для того, что бы оставаться конкурентоспособным стремятся решить проблему, в первую очередь качественно а не быстро.
в первую очередь качественно а не быстро.
Большое заблуждение и обобщение. Возьмем gitlab. Во многом образец open source продукта, только вот его приоритеты это набивание продукта фичами, а не исправление проблем. И исправлению ситуации не способствует даже то, что у них полно клиентов, которые им платят деньги и жалуются на проблемы постоянно.
Напротив, ненавистный golang именно по такой модели и разрабатывается. Очень осторожная разработка с предельным вниманием к качеству кода и большими сроками стабилизации продукта до того, как будет выпущена новая версия. 3 месяца разработки, 3 месяца тестирования и исправления проблем, релиз. Только вот автор там тоже будет не кстати. Там никому не нужно творчество и фантазия ради творчества и фантазии. Нужны простые и эффективные решения. А сложное, даже если оно быстро и полезно, порой и не примут. Такое уже было неоднократно. Недавно вон хотели более хитрый алгоритм сортировки добавить, но большая сложность кода стала препятствием. Не оправдывал прирост в скорости такую сложность.
Да, согласен. Но так продукт бездумно набивается «от души». Ведь куда приятнее запилить что то новое а не фиксить баги =) А большое количество клиентов так как они почти монополисты на этом ранке. Ну и потом… не смотря на то, что я не владею большой информации по развитию этого проекта, смею предположить что большое количество клиентов приводит к появлению так называемых «спонсоров» которые «спонсируют» не сам проект а определенные фичи, которые там в большом количестве появляются. А это, в свою очередь, как раз таки и сваливает проект от теплого и лампового open source в сторону ужасного и требовательного бизнеса. В этом плане golang наверное ближе к идеологии opne source чем gitlab. Имхо.
Это тоже. Жалоб среди пользователей бесплатной версии, что все больше внимания уделяется фичам, которые попадают только в платную версию, тоже достаточно. К тому же, если раньше было две версии, платная и бесплатная, то теперь там несколько уровней платности и логика, по которой фичи отбираются в тот или иной уровень, порой непонятна совершенно. Оправдание всегда одно, мол, фичи в платную версию идут те, которые для небольших команд ненужны. А если команда большая, то платите. Явно ноги растут из клиента, который попросил фичу, которая и была бы полезна небольшим командам, но некрасиво будет раздавать ее бесплатно. Так то gitlab конечно крут, конкурентов у него наверное действительно нет в плане бесплатных решений, но такая ситуация меня печалит.
Особенно проблемы с недоделкой фич. Многие вещи бросают на пол пути и в итоге оказывается, что, например, новый замечательный репозиторий контейнеров не чистит за собой и забивает людям диски терабайтами мусора. В планах было это сделать к 11.6, которая вышла на днях. План сорвался, т.к. и так туча фич запланировали. Сдвинули к 11.7. А появилась эта фича в 8.8, полтора года назад. Когда они это реально исправят черт его знает, а ведь это очень большая проблема.
Особенно проблемы с недоделкой фич. Многие вещи бросают на пол пути и в итоге оказывается, что, например, новый замечательный репозиторий контейнеров не чистит за собой и забивает людям диски терабайтами мусора. В планах было это сделать к 11.6, которая вышла на днях. План сорвался, т.к. и так туча фич запланировали. Сдвинули к 11.7. А появилась эта фича в 8.8, полтора года назад. Когда они это реально исправят черт его знает, а ведь это очень большая проблема.
Заниматься творчеством делая очередную систему учёта невозможно, если только вы не придумали новый подход к учету. Придумать его тяжело, потому что миллион людей уже об этом думали. А раз так, то делая учетную систему вы выполняете функции ремесленника, а не творца. Язык программирования тут ни при чем, просто посмотрите на другие задачи.
Проблема с «другими» задачами в том, что прочитав книгу “Go за 21 день» их не решить. Надо много знать за пределами программирования. Например, знать какой-то бизнес, или разбираться в математике и решать с помощью своих знаний задачи. Знание Go и очередного мега фреймворка никаких задач не решает и если это все, что вы знаете, то бизнес поставит вас решать типовые задачи, не требующие творчества и спец. знаний.
Честно говоря я не понимаю откуда такое одобрение у этого поста.
Начиная с сорри мини-выпиндрежа про «следите за пальцами», ханжеских рассуждений про порнуху через впн и пиратство, заканчивая «Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации» — wtf, это не идеализм, это банальное не понимание реальности. В реальности ты волен выбирать работать тебе на бизнес за деньги, или сосать лапу в опенсорсе, или комбинировать так, чтобы максимально удоволетворять свои потребности. Да даже не понятно что тут обсуждать и как это толком связано с названием «Безликий код убьет программирование, и ничего мы с этим не сделаем».
ЗЫ Кто-то должен был это написать — заметка ни о чем.
Начиная с сорри мини-выпиндрежа про «следите за пальцами», ханжеских рассуждений про порнуху через впн и пиратство, заканчивая «Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации» — wtf, это не идеализм, это банальное не понимание реальности. В реальности ты волен выбирать работать тебе на бизнес за деньги, или сосать лапу в опенсорсе, или комбинировать так, чтобы максимально удоволетворять свои потребности. Да даже не понятно что тут обсуждать и как это толком связано с названием «Безликий код убьет программирование, и ничего мы с этим не сделаем».
ЗЫ Кто-то должен был это написать — заметка ни о чем.
НЛО прилетело и опубликовало эту надпись здесь
Точно не путаете ханжество и лицемерие?
НЛО прилетело и опубликовало эту надпись здесь
Не совсем понял. Мне из определения ханжества нравится строчка про «Крайность в осуждении аморальности». По-моему, она тут прямо на лицо, в демонстративной форме. Не знаю как там у других, но просмотр таких вещей, а также обход абсурдных блокировок в стиле DMCA просто отличным применением VPN, наравне со многими другими вещами.
Эка вы лихо просмотр порно с убийством в одну линию поставили…
Искусство нуждается в самоограничении. Хорошие композиторы не жалуются, что нот всего 7. Архитекторы как фигачили всё одинаковыми прямоугольными кирпичами со времён Римской империи, так и до сих пор фигачат. В балете как минимум с XVI века одни и те же характеры и па. Абстракционисты все умели в пропорции и композицию, так же, как до них импрессионисты − в цвета.
Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.
Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.
Я бы сказал бы, что нот таки больше семи.
В хроматическом звукорядке, который используется в современной музыке, рассматривают 9 октав, каждая из которых состоит из 12 нот.
Семь нот — это лишь способ записи музыкального произведения, к которому добавляются знаки альтерации и ключи у нотного стана.
В хроматическом звукорядке, который используется в современной музыке, рассматривают 9 октав, каждая из которых состоит из 12 нот.
Семь нот — это лишь способ записи музыкального произведения, к которому добавляются знаки альтерации и ключи у нотного стана.
А бит имеет аж два состояния — вот уж простор для творца. Но почему от машинных кодов отказались
Пусть все решит естественый отбор.
Пусть клмпании, желающие «урвать кусок прямо сейчас» его получат, и с ним в зубах сдохнут. Не мешайте им убивать себя.
А сами пока пилите свои проекты по всем правилам.
Проект жив только в руках Мастера.
В руках «эффективного менеджера» он умирает.
Пусть клмпании, желающие «урвать кусок прямо сейчас» его получат, и с ним в зубах сдохнут. Не мешайте им убивать себя.
А сами пока пилите свои проекты по всем правилам.
Проект жив только в руках Мастера.
В руках «эффективного менеджера» он умирает.
Какой бизнес, такое и IT. Иметь программу более надёжную, чем сам бизнес, бессмысленно. Это будет ситуация «без штанов и в шляпе».
90% компаний закрывается в течение первого года, 3% продолжает существовать более 3 лет.
90% компаний закрывается в течение первого года, 3% продолжает существовать более 3 лет.
Боюсь, что изобретение общего искусственного интеллекта убьет программирование намного раньше.
Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.
Философия языка — создавать одинаковые проблемы, чтобы их решали одинаковым образом.
Видел я таких, «творческих» программистов. И инженеры из них херовые, и пользы для бизнеса не сильно много.
Не надо оправдывать говнокод творчеством. Программы надо писать понятно, прозрачно, эффективно, быстро и стабильно. Ваш же пост все это подводит под хотелки бизнеса и кровавых топ менеджеров, и вообще, мол, это все от лукавого.
А знаете, в чем дело? В том, что вы сами признавались n публикаций назад, что Вы вечный мидл. Максимализм и показушничество.
PS. Если что, я и сам Go не люблю, но по другим причинам. Основной язык С++
Не надо оправдывать говнокод творчеством. Программы надо писать понятно, прозрачно, эффективно, быстро и стабильно. Ваш же пост все это подводит под хотелки бизнеса и кровавых топ менеджеров, и вообще, мол, это все от лукавого.
А знаете, в чем дело? В том, что вы сами признавались n публикаций назад, что Вы вечный мидл. Максимализм и показушничество.
PS. Если что, я и сам Go не люблю, но по другим причинам. Основной язык С++
Творчеством занимаются маркетологи, дизайнеры и специалисты в предметных областях, которые формируют концепцию продукта. Программисты занимаются переводом этих фич в машинный язык на более низком уровне.
Может быть автор ошибся с профессией: думал, что программист — это такой сумрачный гений и рок-звезда, который решает всё: от списка фич продукта до списка флагов компилятора, а на деле оказалось, что программист — это что-то вроде переводчика, который может переводить, но не может ничего сказать самостоятельно, поскольку самостоятельно говорят другие — компетентные — люди.
Может быть автор ошибся с профессией: думал, что программист — это такой сумрачный гений и рок-звезда, который решает всё: от списка фич продукта до списка флагов компилятора, а на деле оказалось, что программист — это что-то вроде переводчика, который может переводить, но не может ничего сказать самостоятельно, поскольку самостоятельно говорят другие — компетентные — люди.
Я согласен с автором в том, что программирование идет по пути бизнеса, но это не программирование, а человечество в целом. Тем не менее, мне кажется, что написание «безликого» кода, хоть и удовлетворяет нуждам бизнеса и всячески им поддерживается, но никак не лишает профессии программиста творчества. Продукт работы программиста не строки кода, которые могут быть безликими, а цельная программа. Это как сводить рисование к тому, как водить кисточкой. Творчество не в том, что ты водил кисточкой каким то особым способом а в том что ты этой кисточкой создал что то новое.
большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом.
И это маркетинговый обман для того, что бы оправдать синтаксическую бедность языка. То есть исключая абсолютную глупость утверждения в плане логики работы кода и прочего, у golang даже синтаксис иногда позволяет сделать одного и тоже разными способами (тут есть немного примеров). Просто не ведитесь на это. Сюда еще можно докинуть управление зависимостей.
Go — это бизнес-эффект, а не инженерное решение. Он сам себе противоречит. Вот он хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности. Дженерики существуют именно ради надёжности, чтобы предвосхищать потенциальные баги dev-time. И да, они довольно сложны.
Мне кажется, вы как раз тут не правы. Go — это очень инженерное решение, просто оно от хардкорных инженеров и для конкретных задач. И в этой области он дает фору в целом всему, потому что другие языки или довольно сложны для этой задачи, или же просто не подходят.
Но вот из-за хайпа go потащили всюду и тут уже пришел бизнес с требованием написания кода быстро и с большим количеством абстракций, что бы сам по себе код был довольно гибок. Вот и приехали дженерики и прочие решения.
Думаю, вы полностью правы. Go создан программистами старшего чем мы поколения. Со своим видением и опытом. Можно сказать, что этот опыт они включили в язык как набор шаблонов и требований.
*Дженерики не приехали :) Их еще пару лет будут аккуратно смотреть и пробовать.
у golang даже синтаксис иногда позволяет сделать одного и тоже разными способами
И это даже авторами считается досадным упущением, которое они пытались исключить из языка, но не получилось. Сейчас идет второй заход и уже есть предложения убрать эти дублирующие конструкции, но обратная совместимость это вряд ли позволит.
И никакого маркетингового обмана в этом нет. Для кого бедность языка, а для кого прекрасный дизайн языка, позволяющий писать ясный код. Возможность писать одно и тоже разными способами для меня как раз признак низкого качества языка и нагромождения фич. И го был бы еще лучше, если бы в нем, например, убрали new.
Тоже самое с управлением зависимостями. Одна из самых прекрасных фич языка. Сколько проблем и гемора предотвращено просто грамотным дизайном модулей. И проблемы тут возникают только тогда, когда приходишь с другого языка, где можно творить что душе угодно и не важно, чем это обернется в будущем.
И никакого маркетингового обмана в этом нет. Для кого бедность языка, а для кого прекрасный дизайн языка, позволяющий писать ясный код. Возможность писать одно и тоже разными способами для меня как раз признак низкого качества языка и нагромождения фич. И го был бы еще лучше, если бы в нем, например, убрали new.
Ну, фиг с ним с синтаксисом. Но на уровне логики приложения у вас такого не получится достигнуть в целом никогда. А синтаксические трюки дело десятое, на мой взгляд.
Тоже самое с управлением зависимостями. Одна из самых прекрасных фич языка. Сколько проблем и гемора предотвращено просто грамотным дизайном модулей. И проблемы тут возникают только тогда, когда приходишь с другого языка, где можно творить что душе угодно и не важно, чем это обернется в будущем.
Я прошу прощения, это вы про go mod, который появился сравнительно недавно, а до этого полный трешак с go get и отсутствием управления зависимостей. Причем каждый другой новый язык с самого начала вводит какие-то пакеты или модули, а вот golang решил отличится.
Ну, фиг с ним с синтаксисом. Но на уровне логики приложения у вас такого не получится достигнуть в целом никогда. А синтаксические трюки дело десятое, на мой взгляд.
С этим то я не спорю и вообще непонятно откуда даже такое взялось. Я к тому выше и писал тоже. Смешал все в кучу автор зачем-то. Дублирования нет в языке, но это инструмент. Писать на нем можно что угодно и как угодно. Твори сколько влезет. Просто базовые все конструкции максимально ортогональны, поэтому код на го обычно не нужно расшифровывать. Он предельно ясным получается во многом благодаря такому дизайну языка.
Я прошу прощения, это вы про go mod, который появился сравнительно недавно, а до этого полный трешак с go get и отсутствием управления зависимостей
И про то, и про другое. Это чуждо может быть для других языков, но go get привил подход, когда мастер ветка всегда стабильна. Что go mod к этому добавил, это версионирование, которого действительно не хватало. Каждый решал это сам — сабмодулями в гите, сторонними решениями вроде dep и т.д. В плане тулинга был пробел и тут явно видны ноги гугла с его монорепой, а вот сам дизайн модулей — он сделан прекрасно и одна из лучших фич языка.
Сейчас вот главное, чтобы вендоринг оставили такой, какой есть. А то вместе с go mod убрали его поддержку, но под напором общественности вернули. Правда в каком-то корявом виде с необходимостью передать флаг, чтобы включить ее.
Это чуждо может быть для других языков, но go get привил подход, когда мастер ветка всегда стабильна
Хах, нет. Просто go get привел к версинности по коммитам, а в куче проектов как мастер ветка собирается через раз, так это и происходит. В хороших проектах проектах так и без специальных тулзов делают.
но go get привил подход, когда мастер ветка всегда стабильна.
Вы рассчитываете на определенный API определенной версии библиотеки, и при этом ссылаетесь на ее master branch? Звучит безумно. Он то может быть стабильным, только вот обратной совместимости API никто не гарантирует. Меня это оттолкнуло от GO с самого начала, вместе с идиотским GOPATH и отсутствием эксепшенов. Радует, что первый пункт уже устарел, надеюсь что решили и остальные проблемы.
НЛО прилетело и опубликовало эту надпись здесь
А я всегда говорил что сначала архитектура, потом парадигма, а потом язык программирования… если уж говорить о ЯП
Не могу согласиться с утверждением, что сложность нужна для надежности.
И это не изобретение Go — ограничение языка для более простой и надежной работы. Это просто потомок альтернативной ветви эволюции императивных языков Modula/Oberon/Pascal. В чем-то это детё Вирта. А он всю жизнь именно борьбе со сложностью за надежность и посвятил. Пройдитесь по мшистым форумам Оберона, там все несколько иное, но надо отдать должное, народ пишет умные и надежные системы.
Как все запущено. Вам к терапу.
Я не имею ничего против дженериков, но мне до сих пор не понятно, почему в какой-то момент времени их наличие стало критерием качества языка?
Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.
Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.
Если вы не можете нормально писать без дженериков, то вы, очевидно, не сможете писать нормально и с ними.
Если вы не можете нормально писать с перегрузкой функций, то вы, очевидно, не сможете писать нормаль и с ней. Поэтому давайте называть функцию print, print1, print2.
Дженерики как минимум нужны для универсальных контейнеров, функций и прочей фигни без потери типа. То есть можно делать каст типа обратно, но это не очень удобно.
Вы говорите «нужны» там, где следует говорить «удобны».
А вообще мне очень нравится ваше определение: нужны для универсальных контейнеров, функции и прочей фигни.
А вообще мне очень нравится ваше определение: нужны для универсальных контейнеров, функции и прочей фигни.
Вы говорите «нужны» там, где следует говорить «удобны».
Они именно нужны. Потому что если их нет, вы начинаете их эмулировать путем приведение типов туда и обратно.
Или, тяжело представить, придумаю, как обойтись без этого?
Не это ли та свобода на отсутствие которой так сетует автор?
Не в том ли проблема, что зачастую дженерики (хоть и, повторюсь, я считаю их хорошим инструментом) в руках непризнанных творцов становятся просто средством латания кривой архитектуры?
Хорошие программисты пишут хорошо на любом языке (кто-то умудряется даже в эзотерические уметь), остальные предпочитают обсуждать «слабые стороны» языков, в которые они не смогли.
Се ля ви.
Возьмите любой крупный проект и погрепайте сколько там приведений к пустому интерфейсу и назад. Почти все эти случаи из-за отсутствия дженериков. Даже больше того, в самом языке массивы — это тоже дженерики, вы без них не можете писать код нормально.
Правда, хорошие программисты могут писать и на ассемблере, но зачем специально вставлять им палки в колеса то?
Ну Вы, конечно, молодец, низвели тему беседы к словоблудию.
Можно дерево «срубить» быстро и удобно бензопилой, а можно долго и усердно топором.
Так вот если я ценю время и силы — мне нужна бензопила, если я хочу заняться известным делом, сродни библейскому Ананию, то мне пойдёт и топор, а может и ложка.
Можно дерево «срубить» быстро и удобно бензопилой, а можно долго и усердно топором.
Так вот если я ценю время и силы — мне нужна бензопила, если я хочу заняться известным делом, сродни библейскому Ананию, то мне пойдёт и топор, а может и ложка.
Вашему лагерю пора бы уже определиться: то ли вы за свободу и творчество, то ли за удобные и простые инструменты.
А то когда речь заходит о дженериках, вам подавай готовую спеку языка, предполагающую решать конкретную проблему конкретным способом, во всех остальных случаях у вас этот же подход вызывает истерику и вот такие статьи.
П — последовательность.
А то когда речь заходит о дженериках, вам подавай готовую спеку языка, предполагающую решать конкретную проблему конкретным способом, во всех остальных случаях у вас этот же подход вызывает истерику и вот такие статьи.
П — последовательность.
Я не имею ничего против дженериков, но мне до сих пор не понятно, почему в какой-то момент времени их наличие стало критерием качества языка?
Один из критериев "качества языка" — возможность лаконично выражать разные абстракции. Простой пример — коллекции элементов различных типов, но не стандартные, а создаваемые пользователем языка (ну, какой-нибудь R-Tree или Trie, или LinkedHashMap, если у вас нет jvm). Для этого могу вспомнить 3 подхода:
1) Динамические языки. В коллекцию можно добавить любой тип, проверки во время компиляции нет. Просто, но наличие юнит-тестов желательно.
2) Копипаст. Адовые заклинания на препроцессоре С, кодогенерация или ручной копипаст. Стандартного способа нет, используются нестандартные, кто во что горазд.
3) Статические языки с generic'ами, ко- и контравариантностью типов-параметров. Позволяют описать коллекцию, наложить ограничения на типы-параметры, проверить ограничения во время компиляции. Сложно, но надёжнее и быстрее, чем динамических языках.
Если ваш язык статически типизован, приходится выбирать между 2 и 3. Подход 2 будет похуже из-за ненаглядности исходного кода, неожиданных ошибок, отсутствие поддержки IDE. Подход 3 сложен, но основная сложность в написании компилятора языка и IDE.
Конечно, если ваши структуры данных настолько просты, что хватает стандартных, вам ни к чему вникать в ковариантность типов и в вот это вот всё. Но для достаточно сложных случаев проще вникнуть, и взять подходящий язык.
Простой пример — коллекции элементов различных типов, но не стандартные, а создаваемые пользователем языка«Янепрограммист», но для решения чего-то подобного в чистом C у меня была структура из char'а, указывающего тип и union'а со всеми комбинациями элементов. Это-вот не оно? Я просто не понимаю…
Или речь о том что типы проверять еще на этапе компиляции? Как в шаблонах С++? Но так если в массиве элементы разных типов, то такое не сработает, все-равно придется их в рантайме определять.
НЛО прилетело и опубликовало эту надпись здесь
Суть в том, что один (!) раз пишется реализация какого-нибудь LinkedHashMap, а потом другие программисты используют тот же код 100500 раз без модификаций, независимо от типов данных, что им требуется хранить в map'е. Тег для типа (ваш char) и поле union — немного не то, т.к. union нужно для каждого нового типа расширять.
Конечно, можно реализовать требуемое и на языке без шаблонов (например, передавая в функцию-конструктор нашего LinkedHashMap размер типа и указатель на функцию его освобождения, etc), но на языках с шаблонами/generic'ами это делается гораздо менее больно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
На заводе ему тем более никто не даст вылизывать код просто потому, что это невыгодно.
Если оборудование выпускаемое заводом имеет ограничение памяти в 128 килобайт, а код в этот лимит не лезет, то код вылизывать ПРИДЁТСЯ.
Да нет, обычно как раз слышно что времени просто куча в таких местах свободного. Задачу сделал что поставили — и сиди, занимайся чем хочешь. Не везде, понятно, но много где. Правда там и платят меньше, года полтора назад например спрашивали не хочу ли к ним пойти на 20к ЗП (не миллионник), при том что это бы даже тогда означало бы проседание по ЗП в полтора раза. А сейчас и вовсе в 2.5. Свободное время это конечно хорошо, но 20к даже для нашего городка копейки.
втиснуть 3D-алгоритм в ПЗУ боеголовки
пишутся на других языках
Намекаете, что сборщик мусора в боеголовке совсем ни к чему?
Чем больше что-то развивается, тем больше упрощаются и универсиализируются его элементы. Так будет и с программированием. После упрощения языков программирования и выработке универсальных подходов, будет создано проф. ПО, которое даст возможность создавать код не программисту, а простому выпускнику ПТУ. Зародыши уже есть в виде визуальных редакторов кода, но новое ПО будет намного серьезней. И это все, может, плохо для программера, но очень хорошо для всех остальных.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Уже были CASE-системы, и где они? А UML с кодогенерацией? А про IDEF_ вы помните?
Несомненно, скоро какие-то задачи будут автоматизироваться простым наговариванием электронному ассистенту, но до упрощения разработки прочти как до ИИ, пока что она только усложняется. Проще стало решать вчерашние задачи, это да, но с развитием возможностей растут и запросы.
Несомненно, скоро какие-то задачи будут автоматизироваться простым наговариванием электронному ассистенту, но до упрощения разработки прочти как до ИИ, пока что она только усложняется. Проще стало решать вчерашние задачи, это да, но с развитием возможностей растут и запросы.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Как б-женька смолвил, чуть не расплакался. Всегда стараюсь искать работу с тех. стеком, отбрасывающим на входе как можно больше бездарей и вредителей (например такие, которые делают rm -rf tests/, если у них перестали проходить какие-то тесты, когда их на недельку оставили одних в проекте, случай из личной жизни), тем временем вижу всё меньше хороших вакансий, и кругом всюду требуются сплоншняком PHP/JS/Python/Ruby/Go-говноклады. Тенденция давно задана, и средний уровень престижа профессии стремится пробить всё новое дно. Хорошее программирование не будет убито, оно и так уже почти мертво.
Проблема в том, что автор прав до определенного предела. До тех пор пока этот безликий подход приносит деньги. Но наступает предел. Предел безпомощности и ошибок слабограмотных специалистов. Когда софт перестает давать деньги, и когда бизнес вдруг оказывается без возможности удовлетворять потребности. И тогда специалисты, настоящие, оказываются нужнее. И это ОБЫЧНЫЙ результат бизнеса, который делает все быстро, мало того закономерный и прогнозируемый. Поэтому — безликий простой код — удел стартапов. А потом начинается путь Facebook, Google и иже с ними — свои компиляторы, библиотеки, опережающие все, что было до этого, вот тогда мы — настоящие фанатики своего дела и начинаем быть востребованы. Бизнем должен ушибиться. Тогда он умнеет.
Начал читать, не посмотрев автора, всю статью казалось, что мне знаком этот стиль от которого веет самолюбованием и завышенным чсв, но после слов «любой лох посидит на курсах год», не поверите, я узнал автора)) Специально посмотрел в конце и вообще не удивился своим «экстрасенсорным» навыкам)
По поводу статьи в целом можно согласиться, к сожалению, давно пройден тот этап, когда ИТ действительно жило прогрессом, даже менталитет сферы был другим, сейчас же даже начинающих туда влечет больше денежная и бизнес-составляющая, к сожалению, а каков запрос, такое предложение… печально
По поводу статьи в целом можно согласиться, к сожалению, давно пройден тот этап, когда ИТ действительно жило прогрессом, даже менталитет сферы был другим, сейчас же даже начинающих туда влечет больше денежная и бизнес-составляющая, к сожалению, а каков запрос, такое предложение… печально
то мы придем к самой кривой и не оптимизированной автоматизации, какую только можно представить.
Ничего гугл что-нибудь новое запилит для оптимизации неоптимизированной автоматизации, GoPTimizer. Согласен с автором, Go это какое-то обезличивание программирования.
Хмм..., сам никогда не понимал, зачем снижать порог входа в область.
Это же ведь натуральный отсев, кто сможет преодолеть, а кто нет.
В итоге качество станет только лучше.
Хотя понятно, что до какой-то степени материал нужно делать понятным для других.
Это же ведь натуральный отсев, кто сможет преодолеть, а кто нет.
В итоге качество станет только лучше.
Хотя понятно, что до какой-то степени материал нужно делать понятным для других.
Не понимаю автора со всей силы. Безликий код — это отлично. В моей практике, к сожалению, "творчество" чаще всего выражается в не следовании стандартам и не очевидным решениям, над которым далее приходится ломать голову, бывает по несколько дней. С комментариями в стиле "добавь к счетчику, сколько времени ты потратил на это метод".
Особенно это касается больших проектов на десятки/сотни программистов. Как показывает (моя) практика — чем строже стандарты, кодстайлы и вот это вот все — тем лучше. То, что в Go-шке сделали gofmt и утвердили стандарт оформления — это замечательно. Сообществу PHP на понимание необходимости такого стандарта потребовалось более 10 лет!
Немножко расширю
Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом.
За это вам и платят.
Бизнес не хочет зависеть от случайностей.
А вы хотите?
Мысль, что плохое настроение ведущего разраба отнимет у бизнеса кусочек прибыли, не нравится топ-менеджерам.
Мысли о том, что плохое настроение ведущего разраба приведет к проблемам в:
- медицинском ПО будут причиной постановки ошибочного диагноза
- банковском ПО приведут к ошибочному обнулению счета
- складском ПО приведут к его разрушению, или остановке работы
- ПО управления АЭС приведут к катастрофам
- ПО управления транспортных системах приведут к катастрофам
...
меня пугают до усра*ки. Если ваше плохое настроение влияет на вашу работу — сорян, вас надо гнать ссаными тряпками.
Мои мозги обслуживают мелкие ежеминутные хотелки, чтобы люди принесли мне деньги, чтобы я тоже удовлетворил свои хотелки.
Если эти хотелки не нужны — ваша работа как бы тоже.
Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.
Если для вас эти "лохи" являются конкурентами — вы один из них, что поделать.
Мой tslint не разрешает добавить мне лишний пробел. Мой код не билдится, если я назвал переменную не с той буквы.
Ок, что происходит в противном случае? Ваш код упадёт / или будет работать не прогнозируемо уже в рантайме. Исправлять потом сложнее и дольше. Спасибо говорить за это нужно))
Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже». Звучит абсурдно?
Вовсе. Вы не замечали, что обычно чем выше квалификация у инженера — тем проще читать его код? Код же не пишется один раз и как бы всё. Он поддерживается, тестируется, модифицируется и в принципе читается на много больше раз, чем пишется, при этом не только вами.
Программируя, я хочу заниматься творчеством.
И в чем проблема? Творите opensource и будет вам счастье, радость, радуга.
Хочу иметь огромное число опций, когда дизайню систему.
Ага, а потом сводить вместе callback + Promise + async-await + *Sync, отличная идея. Чем больше у вас вариантов — тем больше сил нужно потратить на их объединение.
Философия безликого кода хочет сделать из меня машину, которая копипастит бойлерплейт.
Если "безликий код" делает из вас машину, ну что ж это печально. В моем текущем проекте, даже с очень жесткими стандартами качества / оформления и кучей соглашений — я спокойно могу определить кто автор того, или иного куска кода, не смотря в blame.
Если программирование сейчас свернет на дорожку Go и безликих практик, то мы придем к самой кривой и не оптимизированной автоматизации, какую только можно представить.
Неа, задачи перейдут на более высокий уровень. Вы часто ассемблере пишете, или на машинных кодах?
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.
Ага, и превратить это в некую секту для избранных, с десятиной и всем чем положено. Со сборами по пятницам ночью, когда все вернутся с не автоматизированных заводов и фабрик. Еще ритуалы нужны по эффектней.
Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым.
Когда вы слышите подобное — мне так почему-то кажется, вы уже знали, что это возможно. Раскрою секрет — так происходит НЕ всюду.
Я бы всеми силами держал порог входа в программирование как можно выше.
Дык не вопрос, есть Haskell, Erlang, Scala,… На том же Erlang действительно крутых специалистов в Украине человек 50 может не набраться. В чем проблема? Не нравится Go — не пишите на нем.
Возможно автор мнит себя Моцартом, а на самом деле он только Сальери.
Творчество сосредоточено не там, где автор пытается его искать. Разработка готового продукта под требования клиента — это, как правило, ремесло. Разработка новых решений, на основе которых строятся готовые продукты, это творчество, придумать nginx, во времена, когда альтернатив апачу не было, это творчество, задуматься о NoSQL, когда везде был только SQL, это творчество. Появляются новые языки, как результат осмысления прошлого опыта, и пусть не все из них останутся на десятилетия, как Си или Джава, сам факт их появления — это тоже мысль и творчество.
Есть желание творить? Определитесь со своими предпочтениями, и творите на здоровье. Например язык Rust, начинался как проект одного человека, а сейчас его перспективы весьма не плохие.
Творчество сосредоточено не там, где автор пытается его искать. Разработка готового продукта под требования клиента — это, как правило, ремесло. Разработка новых решений, на основе которых строятся готовые продукты, это творчество, придумать nginx, во времена, когда альтернатив апачу не было, это творчество, задуматься о NoSQL, когда везде был только SQL, это творчество. Появляются новые языки, как результат осмысления прошлого опыта, и пусть не все из них останутся на десятилетия, как Си или Джава, сам факт их появления — это тоже мысль и творчество.
Есть желание творить? Определитесь со своими предпочтениями, и творите на здоровье. Например язык Rust, начинался как проект одного человека, а сейчас его перспективы весьма не плохие.
У автора дар разжигать. Причем разжигать грамотно, себе в плюс. :) Я бы порекомендовал посмотреть интервью с автором, чтобы понять откуда ноги растут habr.com/post/420321
Программирование движется по пути всех предыдущих профессий. И я бы не стал примешивать сюда ИИ и автоматизацию — можно с ними, можно без них, картина та же.
Несколько тысяч лед назад спроектировать двухэтажный дом могли единицы. И им нужны были сотни а то и тысячи носильщиков камней. Потом появились «типовые архитекторы», которые должны были проектировать по типовым схемам и проектам, но мы всё ещё знаем имено «творцов» (например Растрелли). А типовые архитекторы видимо возмущались, что им не дают творить. Теперь таких типовых архитекторов вероятно можно заменить софтом — никому не нужно творчество в прокладке труб в туалетах. Однако остались как гении уровня Захи Хадид и Хундертвассера, так и просто местные архитекторы, в результате творчества которых в моём районе все дома немного необычные. Плюс тут в том, что милиарды человек имеют крышу над головой, при этом не переживают, что это нестандартное решение развалится от порыва ветра.
С одной стороны, многих кодеров как и архитекторов, прокладывающих трубы, можно будет заменить автоматизацией. С другой, всегда останутся те, кто будут очерчивать общие контуры домов или софта, а дома и софт буду становиться дешевле, доступнее, массовее. Нужно всего лишь продолжать развиваться.
Несколько тысяч лед назад спроектировать двухэтажный дом могли единицы. И им нужны были сотни а то и тысячи носильщиков камней. Потом появились «типовые архитекторы», которые должны были проектировать по типовым схемам и проектам, но мы всё ещё знаем имено «творцов» (например Растрелли). А типовые архитекторы видимо возмущались, что им не дают творить. Теперь таких типовых архитекторов вероятно можно заменить софтом — никому не нужно творчество в прокладке труб в туалетах. Однако остались как гении уровня Захи Хадид и Хундертвассера, так и просто местные архитекторы, в результате творчества которых в моём районе все дома немного необычные. Плюс тут в том, что милиарды человек имеют крышу над головой, при этом не переживают, что это нестандартное решение развалится от порыва ветра.
С одной стороны, многих кодеров как и архитекторов, прокладывающих трубы, можно будет заменить автоматизацией. С другой, всегда останутся те, кто будут очерчивать общие контуры домов или софта, а дома и софт буду становиться дешевле, доступнее, массовее. Нужно всего лишь продолжать развиваться.
К сожалению, деньги еще не отменили, поэтому нужно писать не то, что хочется, а то, что требуют. Но это не значит, что нужно делать это круглосуточно. Выделите время на хобби и пишите в свое удовольствие.
Я вот пишу для себя на Ассемблере Масм в npp — никаких «умных компиляторов», «умных IDE» и прочего. Только творчество, эксперименты. На заказ, к сожалению, это будет слишком долго и никому не нужно. Но, для работы на заказ есть другие вещи, скажем, C++17 и Visual Studio.
Я вот пишу для себя на Ассемблере Масм в npp — никаких «умных компиляторов», «умных IDE» и прочего. Только творчество, эксперименты. На заказ, к сожалению, это будет слишком долго и никому не нужно. Но, для работы на заказ есть другие вещи, скажем, C++17 и Visual Studio.
НЛО прилетело и опубликовало эту надпись здесь
Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Есть подозрение, что порог входа и так слишком высокий. Только не потому, что кто-то так специально сделал. А потому что софт/инструменты/языки/конечные продукты — сырые. (Самое время вспомнить байку про Джона — серийного программиста). И виноваты в этом все ;) С одной стороны бизнес, который не даёт время сделать хорошо. С другой стороны программист, который занимается избыточным перфекционизмом там, где можно было бы сделать просто. Да и вообще, просто — это не всегда плохо. Часто это хорошо :)
Да грустно наверное автору. Думал вот плтрачу пол жизни буду изучать все и стану крутым программистом незаменимым супепстаром и покажу всем кто тут самый умный. А в итоге профессия поменялась так сильно что любой новоиспеченный мидл ничем не хуже тебя.
Проблема в том, что Пикассо устраивается в бригаду маляров, которые красят стены или заборы и получают оплату за покрашенные квадратные метры, а не за изящество мазка кисти. Маляры на гениальность не претендуют и довольны зарплатой, а Пикассо страдает. В этом бизнесе Пикассо лишний. Такова суровая правда жизни.
Кажется, что автор чем-то обижен на Go. Может его набирающей оборот популярности? А на самом деле Go абсолютно не отменяет никакие парадигмы программирования, практики и шаблоны. И на Go можно написать плохую программу.
Вот тут рассказывается про женерики в Go 2. Будут, всему своё время.
Коллеги, меня все это зацепило, как написал выше. Но! Как показывает многолетний опыт разработки — реально мало профессионалов… Найти C# прокачанного программиста — проблема. Да вообще в любой среде… Надо прособеседовать кучу людей, и то не факт, что найдешь. И дело не в деньгах. Так что миддлы на то миддлы. Никогда не обгонят, если не будут учится.
Не парься бро. Когда появились фотография тоже говорили: вот все теперь художники вымрут, тоже самое было с театр vs кино, кино vs TV, TV vs internet.
Да появятся ремесленники от программирования, потом их заменят автогенераторами, но «художники» которые смогут реализовать идею «изящно» всегда будут.
Да появятся ремесленники от программирования, потом их заменят автогенераторами, но «художники» которые смогут реализовать идею «изящно» всегда будут.
Да, есть такая проблема, когда хочется быть свободным художником, а зарплату получать по тарифу (XX$/час). Надо выбрать что-то одно из двух. Или можно быть художником на бюджете у корпорации (R&D, например). Только для этого надо быть ещё и очень крутым (чтобы пройти отбор из кучи человек на место), и везучим.
Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар.
Хочу вас расстроить, но этот хоорор уже вокруг нас.
Сейчас вы можете писать очень много умных вещей, но компилятор потом все ваши умности конвертнет в векторные вычисления и прочие совершенно нечеловеческие паттерны. Нечеловеческие в том с смысле что такой код люди написать конечно могут, но потом прочитать и понято что этот код делает смогут не многие и не сразу.
А вы не пробовали начинать получать удовольствие от процесса а не от результата (пусть за результат болит голова у менеджера)? Вы продумали архитектуру, нашли интересные пути реализации, написали код, и вот программа заработала. Я, например, лично от этого и получаю удовольствие, а как ей потом будут пользоваться, по сути не имеет значения (даже если никто не будет пользоваться, я не обижусь), я свою порцию «наркотика» получил.
Как в старом анекдоте
Женщина в магазине просит отпустить ей 30 метров бязи. — А зачем Вам так много? — интересуется продавец. — Я хочу сшить себе ночную рубашку. — Ну, на рубашку Вам в 3-х метров хватит. — Дело в том, что мой муж научный работник, и его процесс поиска интересует больше, чем результат.
Если в Go каждая задача имеет только одно решение, то значит это и не язык программирования вовсе. Это некая сжатая библиотека (кодовая база), для разжатия нужного сегмента которой требуется программист.
Можно ещё провести аналогию с ДНК…
Можно ещё провести аналогию с ДНК…
Необходимость в сложных алгоритмах и архитектурных решениях никакая стандартизация и безликость кода не убъет. К счастью или к сожалению, таких задач их меньше, а для обычного штамповочного кода подойдет и конвеер.
Так что если не нравится быть оператором конвеера, то стоит все-таки углублять свои фундаментальные знания и способности к самообучению и идти уже в системные программисты, а не прикладные.
Потому что готовый продукт важнее его реализации.
Да, да, тысячи раз ДА! Это же самый-самый кайф! Вот ты доделываешь фичу, выкатываешь в продакшен — и жизнь пользователя становится чуточку лучше. У него меньше головных болей, потому что сервис что-то автоматизировал, что-то теперь не нужно делать руками… Или он благодаря твоей работе может интересно провести время, получить удовольствие или расслабиться — привет компьютерные игры, браузеры и т.п. Разве это не офигенно само по себе, что относительно небольшими усилиями ты хотя бы чуточку меняешь жизнь других людей? О_о
Из похожего — съёмки развлекательных видео например. За этот год у меня на махоньком ютубовском канале (40 тысяч подписчиков) зрители насмотрели 2 миллиона просмотров. 22 миллиона минут. 40 человеко-лет. Хотя я со своей стороны затратил за год на эти видео суммарно даже не человеко-месяца. Это же… обалдеть какое соотношение усилий/результата, если попытаться в голове удержать!
Ну и блин, как можно не находить творческих задач даже в «текучке»? Да любая, даже самая шаблонная задача всегда содержит простор для размышлений! Как поменять наименьшее число слоёв, чтобы передать данные отсюда сюда? Как оптимальней распределить работу между клиентов и сервером? Или вот мы делаем в месяц 2-3 рутинные задачи такого типа — как бы это автоматизировать, чтобы рутины вот конкретно здесь стало меньше? И такие задачи на каждом, блин, шагу!
К вопросу о том что убьёт программирование: 20 лет назад говорили о том что кейс-средства убьют программирование. И где те кейс-средства? Есть идеи, почему не убили?
НЛО прилетело и опубликовало эту надпись здесь
Я бы посоветовал автору почитать вот это: The 10 rules of a Zen programmer, особенно обратить внимание на часть 4.
Не убудет у нас работы. Простота кода в восполнится сложностью в чём-то другом. Сейчас это инфраструктура в которой он будет выполняться (microservices, orchestration, containerization,… с чем там ещё сейчас сложно).
Так что работа будет, может просто не совсем в такой форме
Так что работа будет, может просто не совсем в такой форме
Ох уж эти кодеры-элитисты, от них всё зло. Ими движет банальный страх остаться не востребованным, а не радение за "ИСКУССТВО КОДИНГА".
Хочется тебе нечто большего?
Есть ощущение, что ты делаешь ТУПОЕ ГОВНО, ДЛЯ ТУПОГО ГОВНА?
— Ну так развивайся!
Меняй специализацию, изучай новые фишки, куча интересной фигни в этом вашем IT: II, Machine Learning, VR, BlockChain.
Вперёд! Пиши свои мудрёные и изящные алгоритмы, задавай стандарты! А не ворчи, как старый дед, про то какие все вокруг бездари.
Хочется тебе нечто большего?
Есть ощущение, что ты делаешь ТУПОЕ ГОВНО, ДЛЯ ТУПОГО ГОВНА?
— Ну так развивайся!
Меняй специализацию, изучай новые фишки, куча интересной фигни в этом вашем IT: II, Machine Learning, VR, BlockChain.
Вперёд! Пиши свои мудрёные и изящные алгоритмы, задавай стандарты! А не ворчи, как старый дед, про то какие все вокруг бездари.
Не всем дано понять Пикасо, вот вы скажите, лучше ли его картины, чем у нашего Репина? Вы хотите самовыражаться, и не все люди могут это понять, поэтому им нужны простые решения.
fillpackart:
Таки да!
Вот к примеру, беру сейчас мобилу в руки и если честно, то я понятия не имею как много раз разработчики прошивки и программ писали goto? Меня лишь заботит исключительно функциональность и производительность относительно моего субьективного представления. К примеру, если я считаю, что смс-ка должна отправиться за 1 сек., а отправляется за 7-10 сек., то мне абсолютно до лампочки как много хороших практик применил разработчик в коде отправки смс-ки! И так думает почти 95% пользователей ПО.
Далее. Чисто из экономических соображений. N руб. сегодня не равно N руб. завтра! Есть инфляция. Если вы провозитесь с решением на K дней больше находясь в поисках хорошего варианта, хотя можно было написать пусть не идеальное, но рабочее и качественное решение и за это время продукт из-за инфляции упал на 1 руб., то в случае с 1.000.000 пользователей это 1.000.000 руб. А за эти деньги можно много чего для бизнеса решить, к примеру выдать вам зарплату!
Позиция «Мне платят за выбор из разного вариантов лучшее» — ошибочна! Вам платят за решение рабочих задач на уровне «Необходимо и достаточно».
Вы, как разработчик, абсолютно ничем не рискуете. Легко можете поднять мягкое место и найти другого работодателя, который будет вам выдавать новые задачи. А вот работодатель рискует! Продолбанные сроки перед заказчиками — факап. Неуспели поставить пользователям билд, а уже новый год встречают и они не работают и как вывод не покупают софт — факап. И много много других факапов может быть из-за «Я искал лучшее решение». А потом к работодателю приходит Вася и говорит «Я вот тут работал и искал лучшее решение. Месяц прошел. Выдавайте зарплату» и ему как правило насрать, а сумел ли работодатель продать софт или нет
Нужно обычное. Потому что готовый продукт важнее его реализации.
Таки да!
Вот к примеру, беру сейчас мобилу в руки и если честно, то я понятия не имею как много раз разработчики прошивки и программ писали goto? Меня лишь заботит исключительно функциональность и производительность относительно моего субьективного представления. К примеру, если я считаю, что смс-ка должна отправиться за 1 сек., а отправляется за 7-10 сек., то мне абсолютно до лампочки как много хороших практик применил разработчик в коде отправки смс-ки! И так думает почти 95% пользователей ПО.
Далее. Чисто из экономических соображений. N руб. сегодня не равно N руб. завтра! Есть инфляция. Если вы провозитесь с решением на K дней больше находясь в поисках хорошего варианта, хотя можно было написать пусть не идеальное, но рабочее и качественное решение и за это время продукт из-за инфляции упал на 1 руб., то в случае с 1.000.000 пользователей это 1.000.000 руб. А за эти деньги можно много чего для бизнеса решить, к примеру выдать вам зарплату!
Позиция «Мне платят за выбор из разного вариантов лучшее» — ошибочна! Вам платят за решение рабочих задач на уровне «Необходимо и достаточно».
Вы, как разработчик, абсолютно ничем не рискуете. Легко можете поднять мягкое место и найти другого работодателя, который будет вам выдавать новые задачи. А вот работодатель рискует! Продолбанные сроки перед заказчиками — факап. Неуспели поставить пользователям билд, а уже новый год встречают и они не работают и как вывод не покупают софт — факап. И много много других факапов может быть из-за «Я искал лучшее решение». А потом к работодателю приходит Вася и говорит «Я вот тут работал и искал лучшее решение. Месяц прошел. Выдавайте зарплату» и ему как правило насрать, а сумел ли работодатель продать софт или нет
Вы правы, что риски не на разработчики, а на владельце бизнеса. Но ведь и прибыль достается не разработчику, а владельцу бизнеса.
Тут есть очевидный конфликт интересов.
Бизнес заинтересован, чтобы разработчик день ото дня методично выкатывал нужные фичи с приемлемым качеством, т.е. выполнял тупую рутинную, невероятно скучную работу.
Разработчика волнует свой карьерный рост и чтобы работа была хотя бы иногда интересной. Если он не будет изучать новые технологии, то завтра его выкинут с той же работы и наймут, новых которые знают современные языки, фреймворки, платформы. Он пробует всякие новые языки, фреймворки, технологии, подходы и архитектурные решения, которые очень часто бывают плохим решением данной задачи, но хорошии для будущих проектов и карьеры.
Тут есть очевидный конфликт интересов.
Бизнес заинтересован, чтобы разработчик день ото дня методично выкатывал нужные фичи с приемлемым качеством, т.е. выполнял тупую рутинную, невероятно скучную работу.
Разработчика волнует свой карьерный рост и чтобы работа была хотя бы иногда интересной. Если он не будет изучать новые технологии, то завтра его выкинут с той же работы и наймут, новых которые знают современные языки, фреймворки, платформы. Он пробует всякие новые языки, фреймворки, технологии, подходы и архитектурные решения, которые очень часто бывают плохим решением данной задачи, но хорошии для будущих проектов и карьеры.
Уверяю вас, в мире разработки очень много интересных задач и при этом хорошо оплачиваемых. Не надо просто замыкаться только и только в одном куске разработки. Разработка она большая! Это большая вселенная! И надо просто поднимать голову из своего болота, хотя бы изредка и смотреть по сторонам. Тогда интересы многих сторон будут соблюдены, в том числе и интересы разработчика
Будем честными, интересной работы на всех просто не хватит) А способности и навыки объективно у всех разные)
Будем честными интересной работы чуть более чем дохрена!
Есть люди ничем не интересующиеся, к примеру от них можно услышать: «а зачем мне марофон пробегать?» или «А зачем мне в хакатоне учавствовать?» или «А зачем мне на лыжи идти?» или «А зачем мне куда-то ехать пострелять?» или <подставьте, что придет в голову>. Им в принципе вообще не интересно! Уперлись только в одно занятие и сидят в нем.
А есть другие! Они и IronMan-ы проходят. И марафоны бегут. Еще и для мобилы аппликуху запилят и еще 100500 всего. Им все интересно! Как правило у них другой вопрос «Где на все взять время?» ведь все так интересно.
По поводу способностей и навыков: все развивается!
До августа 2016-го я умел плыть только одним стилем «топор ко дну», а в июле текущего 2018-го переплыл Босфор. В прошлом году понятия не имел что такое Promise, а сейчас не только его, но и async\await пишу и не особо боюсь и много чего другого тоже применяю.
было бы желание!
Есть люди ничем не интересующиеся, к примеру от них можно услышать: «а зачем мне марофон пробегать?» или «А зачем мне в хакатоне учавствовать?» или «А зачем мне на лыжи идти?» или «А зачем мне куда-то ехать пострелять?» или <подставьте, что придет в голову>. Им в принципе вообще не интересно! Уперлись только в одно занятие и сидят в нем.
А есть другие! Они и IronMan-ы проходят. И марафоны бегут. Еще и для мобилы аппликуху запилят и еще 100500 всего. Им все интересно! Как правило у них другой вопрос «Где на все взять время?» ведь все так интересно.
По поводу способностей и навыков: все развивается!
До августа 2016-го я умел плыть только одним стилем «топор ко дну», а в июле текущего 2018-го переплыл Босфор. В прошлом году понятия не имел что такое Promise, а сейчас не только его, но и async\await пишу и не особо боюсь и много чего другого тоже применяю.
было бы желание!
Босфор? Круто! А я много лет лелею идею переплыть Гибралтар. Чтобы из Европы в Африку.
Но сейчас читая про Босфор, я понимаю, что надо бы мне с него начать… Гибралтар сильно круче.
Но сейчас читая про Босфор, я понимаю, что надо бы мне с него начать… Гибралтар сильно круче.
Ну смотрите, у нас пяток миллионов интересующихся. И всего миллион вакансий. Хочешь не хочешь — а 4 миллиона в пролете. К слову они и… и… и… — больше минус. Я сам такой что прихожу домой с работы и то новый ЯП изучаю, то пару иностранных учу, то рисовать пробую, то сажусь на велосипед и еду на весь день кататься, да еще и лелею мысль когда нибудь математику подтянуть хорошенько. Сейчас вот меняю полностью стек технологий с 1с на android нативный потому что в 1с стало скучно а андроид интересен. В итоге что? Правильно, из меня и программист так себе, и велосипедист, и языки эти я знаю через пень колоду (в японском пока даже до N5 не добрался, но хоть английский более менее) и прочее в таком духе.
P.S. Несмотря на все эти минусы мне нравится мой стиль жизни, но при этом я прекрасно понимаю что такое распыление скорее всего отсечет меня от интересных мест работы. Я не попаду в те самые 0.1% программистов которые чем то интересным занимаются. Точнее не совсем так, мне было в какой то мере интересно и то чем я занимался раньше, и то чем буду заниматься теперь, но это не настолько интересные занятия чтобы отдать им вообще все свое время.
P.S. Несмотря на все эти минусы мне нравится мой стиль жизни, но при этом я прекрасно понимаю что такое распыление скорее всего отсечет меня от интересных мест работы. Я не попаду в те самые 0.1% программистов которые чем то интересным занимаются. Точнее не совсем так, мне было в какой то мере интересно и то чем я занимался раньше, и то чем буду заниматься теперь, но это не настолько интересные занятия чтобы отдать им вообще все свое время.
В итоге что? Правильно, из меня и программист так себе, и велосипедист, и языки эти я знаю через пень колоду
Почему посредственный?
Вы не задумывались о том, что может быть вам еще каких-то навыков не хватает? Что к примеру у вас с английским? А умеете ли вы продавать идеи? К примеру убедить коллег использовать ту или иную технологию это тоже «продажи».
Огромное кол-во людей стукнувшись о трудность думают, что он сделал все что мог. Буквально недавно у меня был затык в webpack-конфиге. Я реально думал, что меня уже гугл матом посылает. Оказалось, что нет, что можно по-гуглить чуть чуть по-другому и проблема решается.
Это про то, что сделанные нами выводы не факт что истина.
Почему посредственный?
Ну как, алгоритмы и структуры данных знаю очень плохо, ОС писать не умею, математику знаю на уровне школы, и еще много похожих пунктов. У меня Скиена до сих пор не прочитанный, как и «Дискретная математика для программистов», как и таненбаум, как и банда 4-х, как и многие другие нужные книги из за того что времени много на другие интересы уходит.
НЛО прилетело и опубликовало эту надпись здесь
Наблюдаем тут утопические чаяния программистов вернуть утерянное положение средневекового кустаря. Бизнесу не нужны гениальные кустари-кузнецы, которые могут диктовать зарплаты и посылать начальников на три буквы. Бизнесу нужен штамповочный станок по металлу, полная заменяемость работников, способность обучить новопришедшего за пару дней после приема на работу и побольше безработных кандидатов за дверьми на то, чтобы в любой момент восполнить потери персонала.
Загляните на главную страницу докера и поймите, какие образы вызывают у владельцев бизнеса эректильную реакцию: конвейер и панель с тремя кнопками, а не ваши левшовые фантазии.
У бизнеса свои чаяния, а у программистов — свои. В чём-то они могут совпадать, а в чём-то — отличаться. И тут нельзя сказать, что интересы одной стороны однозначно важнее другой — это будет чрезмерным упрощением. Должен быть некоторый взаимовыгодный баланс. А так-то можно дойти до того, что бизнес вообще был бы не против, чтобы программист работал 24/7 и желательно бесплатно, но такого к счастью не бывает.
я не думаю, что здесь уместно сравнивать важность данных интересов, неясно ведь, для кого эта важность. Зато мы можем точно сказать, что сообществу программистов важнее собственные интересы, а сообществу собственников бизнеса — собственные.
Просто по вашей изначальной фразе можно подумать, что пожелания бизнеса важнее, он платит деньги и соответственно диктует что тут и как. И, соответсвенно программисты должны подстраиваться под эти хотелки. Но на практике-то видится совсем другая картина: именно бизнес бегает за программистами, сбиваясь с ног, за любые деньги, обещая немереные плюшки. Среди которых м.б. и творческий процесс в том числе. Так что не всё так плохо, как кажется. Это пока ещё наши программисты научились требовать только денег. А скоро, как только привыкнут к достатку, и этого покажется мало. Тогда среди требований появится и нескучная работа, вот увидите.
Какая классная (без сарказма) получилась дискуссия. Читая комментария и высказывания, сформулировал себя на пару выводов. Первый вывод: я всегда был наиболее счастлив, когда начинал изучать/экспериментировать с новым ЯП. Тот самый, «ламповый» фан/драйв/адреналин когда «ура, ура, оно заработало!!!».
Второй вывод: наиболее удовлетворенным я бываю, когда вижу, что у меня есть выбор, на каком ЯП я могу решить ту или иную задачу (ессно когда нет ограничений в стеке). Т.е. нет плохих языков, просто есть задачи которые для них не подходят.
И да, забыл внести свою лепту в обсуждение: GO интересный язык. Прикольный :) Его ограничения и заставляют как раз заниматься тем самым творчеством :) И иногда, сделав рефакторинг архитектуры, чтобы убрать свои фантастически красивые костыли, понимаешь в чем был смысл этих ограничений. Да собственно говоря это наверное к любому ЯП относится.
Второй вывод: наиболее удовлетворенным я бываю, когда вижу, что у меня есть выбор, на каком ЯП я могу решить ту или иную задачу (ессно когда нет ограничений в стеке). Т.е. нет плохих языков, просто есть задачи которые для них не подходят.
И да, забыл внести свою лепту в обсуждение: GO интересный язык. Прикольный :) Его ограничения и заставляют как раз заниматься тем самым творчеством :) И иногда, сделав рефакторинг архитектуры, чтобы убрать свои фантастически красивые костыли, понимаешь в чем был смысл этих ограничений. Да собственно говоря это наверное к любому ЯП относится.
НЛО прилетело и опубликовало эту надпись здесь
ТС, если хочешь и денег и творчества — иди в ресёрч отдел какой-нибудь большой компании. Там тебе и денег много дадут и твори сколько влезет интересные вещи.
Вот тебе совет. Найди контакт (вот тебе твиттер @lorentzframe) Браяна Бэкмана (он очень дружелюбный и открытой человек) из бывшего Microsoft Research и текущего Amazon Robotics; спроси у него как попасть в этот самый Microsoft Research; набери скиллов которых ещё нет и стучись к ним. Дерзай, в общем!
В посте много уважения менеджерам, вроде как они всегда умные и всегда принимают решения, на чем-то рациональном основанные. Это не всегда так.
С тем же успехом можно сказать, что сегодня любой вчерашний лох-продавала из салона сотовой связи, выбившись в топы, будет указывать всем, как жить.
Что сказать? Ищи место, где боссы адекватны, готовы платить за творчество, и влияй на развитие этого места. Открой курсы программирования, в конце концов, и — твори!
Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.
С тем же успехом можно сказать, что сегодня любой вчерашний лох-продавала из салона сотовой связи, выбившись в топы, будет указывать всем, как жить.
Что сказать? Ищи место, где боссы адекватны, готовы платить за творчество, и влияй на развитие этого места. Открой курсы программирования, в конце концов, и — твори!
Мои мозги обслуживают мелкие ежеминутные хотелки, чтобы люди принесли мне деньги, чтобы я тоже удовлетворил свои хотелки.
Краткое и точное описание любой работы. Мы берём чужую лень, свой мозг (рыбное филе, например, порубить — тоже мозг нужен) и трудимся на неё и за это получаем возможность воплотить свои хотелки и быть ленивыми вне своих областей.
И тем более это справедливо для бизнеса. Бизнес ориентирован на людей и их нужды здесь и сейчас. И это нормально.
Если же Вам хочется и вклад в человечество сделать, и творчеством при этом заниматься, и иметь гарантированный кусок хлеба без давления временных сроков и прочих бизнес-радостей, то надо идти в науку. В разработку действительно сложных, долгосрочных систем для будущего, в разработке которых нужен весь мозг и ещё столько же. Но там, за возможность спокойно жить и творить, отнимают хотелки: финансировние бюджетное, от спонсоров проекта — в лучшем случае. Ну, Вы всё это и так знаете, в общем-то.
>Если меня вышвырнут на улицу, и возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом.
или наоборот))
бизнес плох только тем, что использует любой кусок гуано, если он дешевле других решений. так мы пришли к докерам и оргиям в ansible. и жирнолисам.
или наоборот))
бизнес плох только тем, что использует любой кусок гуано, если он дешевле других решений. так мы пришли к докерам и оргиям в ansible. и жирнолисам.
Система, где все задачи будут решаться только одним способом — это точно не про язык программирования. Всё-таки, это система «полная по Тьюрингу», то есть в ней можно реализовать (теоретически) любой алгоритм.
А то, что происходит автоматический контроль стандарта оформления кода — так это прекрасно! Если есть автоматический контроль, значит где-то рядом есть (или будет) автоматический «бьютифаер». Не нравится имеющийся стиль — переформатировал, так как тебе удобно, поработал, накатил старый «корпоративный» стиль, отправил в Git. В чём проблема?
В Питоне, например, нет скобок и нужно, блин, использовать отступы — это что, ужас-ужас? Да, нас лишили стиля «кирпич кода», однако никто от этого не умер.
иллюстрация из статьи Cryptographic obfuscation and ‘unhackable’ software
А то, что происходит автоматический контроль стандарта оформления кода — так это прекрасно! Если есть автоматический контроль, значит где-то рядом есть (или будет) автоматический «бьютифаер». Не нравится имеющийся стиль — переформатировал, так как тебе удобно, поработал, накатил старый «корпоративный» стиль, отправил в Git. В чём проблема?
В Питоне, например, нет скобок и нужно, блин, использовать отступы — это что, ужас-ужас? Да, нас лишили стиля «кирпич кода», однако никто от этого не умер.
иллюстрация из статьи Cryptographic obfuscation and ‘unhackable’ software
Иммигрант Де'Анджело ехал в поезде из Нью-Йорка в Релли, в Северную Калифорнию. На вокзале его встретил двоюродный брат, и тот заметил, что он был в паршивом настроении.
«Что с тобой случилось?» — спросил его родственник.
«Этот чертов кондуктор все время указывал мне, что делать и чего делать нельзя,- воскликнул итальянец. — Я вытащил сэндвич, а он мне говорит: 'Это тебе не столовая', я налил себе стаканчик вина, а он мне говорит: 'Это тебе не бар', и тогда я не выдержал и отправился в вагон-ресторан, познакомился там с одной симпатичной девчушкой, она повела меня в свое пустое купе, и тут прибежал этот чертов кондуктор, и начал орать под ухо: 'Это тебе не Вирджиния, это тебе не тра****ая Вирджиния'».
Вы понимаете только то, что можете понять. Ваш мозг всегда все объясняет, но эти объяснения — ваши собственные.
«Что с тобой случилось?» — спросил его родственник.
«Этот чертов кондуктор все время указывал мне, что делать и чего делать нельзя,- воскликнул итальянец. — Я вытащил сэндвич, а он мне говорит: 'Это тебе не столовая', я налил себе стаканчик вина, а он мне говорит: 'Это тебе не бар', и тогда я не выдержал и отправился в вагон-ресторан, познакомился там с одной симпатичной девчушкой, она повела меня в свое пустое купе, и тут прибежал этот чертов кондуктор, и начал орать под ухо: 'Это тебе не Вирджиния, это тебе не тра****ая Вирджиния'».
Вы понимаете только то, что можете понять. Ваш мозг всегда все объясняет, но эти объяснения — ваши собственные.
программирование никогда не умрёт, может видоизмениться, как например сейчас мало кто пишет используя команды для процессора, инструменты изменились, много уже написано, стало проще и быстрее писать простые вещи и это привело к тому что бизнес стал использовать освободившиеся ресурсы и просто стал использовать то что раньше было дорого и так будет всегда, как только писать становиться проще, начинают количество и сложность фич резко увеличивается и всё опять на том же уровне где и было раньше.
Тут главное следить за технологиями и вовремя на них переходить, и тогда проблем с тем что работодатель захочет тебя заменить никогда не возникнет
Тут главное следить за технологиями и вовремя на них переходить, и тогда проблем с тем что работодатель захочет тебя заменить никогда не возникнет
Программирование, это прежде всего инженерная дисциплина. Унификация подходов в разработке это хорошо. Если вы претендуете на звание инженера, то надо понимать, что поддержка кода стоит денег причем больших денег. И это дествительно важно. Если вы пишите модуль для поддержки которого требуются дорогой специалист, то это плохой инженеринг. Хороший инженеринг, это когда пишется модуль и его может поддерживать специалист любой квалификации, знающий язык программирования. Именно в этом и есть творчество, то есть разработать простую и элегантную архитетуру.
Если хотите разрабатывать сложные модули, делайте это бесплатно.
Мир устроен так, что программирование ради бизнеса, а не наоборот. И когда вы разрабатываете сложный модуль, то вы увеличиваете стоимость продукта для пользователей.
Вас возможно кто-то учил рациональности, но у этого кого-то мало что получилось. Нет ничего рационального в том что писать код в авторском стиле.
Код это не произведение исскуства, вся суть кода в том чтобы удовлетворить потребность пользователя, пусть даже низменную. А программисты это всего лишь высокоплачиваемый персонал, который обслуживает потребность пользователя. Пользователь с самыми низменными потребностями куда важней программиста.
Конечно можно заниматься творчеством, но это должно быть максимально дешево для пользователя
Программирование, это прежде всего инженерная дисциплина
Не-а. У нас тут в программировании нет практически никаких инженерных метрик, инженерных подходов и в целом какой либо инженерности. То есть, формально можно обмазаться различным computer science, пафосно рассуждать про проектирование систем и прочее, но факты говорят сами за себя:
- Computer science безумно оторван от реальности программирования за рамками каких-то базовых дисциплин. Это проявляется во всем, от научных статей по нейронкам, результаты которых реализуются каким-то школьником с питоном минут за 15, до безумно сложной науки о сервисах, в которых они рисуют воздушные замки с веб-онтологиями.
- Инженерного подхода к ПО в целом тоже исчезающе мало, в целом технологии выбираются на хайпе или же фокусируясь на одном аспекте технологии (она быстрая, надо брать!).
- Инженерной документации по проекту, да и в целом документации очень мало. Нет, правда, вы недавно видели актуальную проектную документацию не в коде, а вот что бы прямо проект-проект?
- Вы только подумайте, у нас ведутся споры о том, нужна ли программисту математика. Можете представить себе такой спор в какой-то инженерной специальности? Думаю, нет.
- Вся теория о том, как правильно программировать покрыта дикой, неформализованной субъективщиной с кучей trade-off. Не очень по инженерному, на мой взгляд.
Ну и да:
Если вы пишите модуль для поддержки которого требуются дорогой специалист, то это плохой инженеринг. Хороший инженеринг, это когда пишется модуль и его может поддерживать специалист любой квалификации, знающий язык программирования.
Такого никогда не будет. У вас в любом случае будет или сложная система, или система, которая умеет довольно мало вещей. В первом случае сложность спрятать не получится, так что специалисту нужно будет в этом как-то разобраться, а во втором случае система скоро будет не нужна. Некоторые специалисты не могут разобраться, скажем, с очередью задач. И что, предложите без нее проектировать?
Хороший инженеринг, это когда пишется модуль и его может поддерживать специалист любой квалификации, знающий язык программирования
Если модуль выполняет сложную задачу, то и код его будет сложным, и его не сможет поддержать специалист любой квалификации. Такого, чтобы вы могли заткнуть любым школьником дыру после ухода сеньора, не будет, это розовые фантазии работодателя. Инженерный подход тут состоит в том, чтобы простые вещи писать просто, а сложные — на адекватном уровне сложности.
Код это не произведение исскуства, вся суть кода в том чтобы удовлетворить потребность пользователя, пусть даже низменную. А программисты это всего лишь высокоплачиваемый персонал, который обслуживает потребность пользователя. Пользователь с самыми низменными потребностями куда важней программиста.Вы слишком принижаете эту профессию, полностью отказываясь от её творческого компонента. Дело ваше, но так делать вовсе не обязательно. Для бизнеса важнее функциональные свойства кода, для программиста — м.б. и эстетические. Тут нужно найти взаимоприемлимый баланс между практичностью и красотой, не ударяясь в крайности. И все будут довольны.
Я не говорю про школьника, я говорю про специалиста. По моему опыту, чем опытней специалист, тем проще работать с его кодом. Любую сложную задачу, нао разбивать на подзадачи. И так далее.
Никакого баланса быть не должно, если программист хочет удовлетворять свои эстетические потребности то пусть делает это за свой счет. За счет пользователя, надо удовлетворять потребности пользователя.
В ИТ делают хорошие вещи, но их процент ничтожно мал. Большинство обслуживает дурацкие потребности, которых раньше просто не существовало, потому что не существовало ИТ. То есть, инженеры не делают великие вещи, инженеры просто поддерживают инфраструктуру перекачки бабла между людьми.
Крайне здравая мысль для эпохи, когда считают, что деньги первичны и вещи сами волшебным образом материализуются из денег («бабло в экономику»)
Хоть один человек понимает сущность денег и самого капитализма, которым принято сегодня безоговорочно восторгаться. А ведь именно он и порождает услуги ради услуг, чтобы главное заработать деньги. И не только в кодерстве, в любой сфере капитализм старается «изобрести потребности, которых не существовало», чтобы «вывыпэ», «бабло в экономику» и все такое, на что фапают капиталисты. А вот созидательный труд и прогрессивные исследования такого гешефта не приносят, поэтому мало интересны «ынвесторам», без которых, по мнению тех же капиталистов, «ыкономика фстанет».
НЛО прилетело и опубликовало эту надпись здесь
(читай — без добровольного удобного обмена ценностями)
Я так и читаю, но вот капиталисты зачастую вообще склонны отрицать не только первичность, а и вообще существование «ценностей», будто деньги — это не внедрение зависимости (а они оно самое и есть, выражаясь кодерскими понятиями) между товаром и потребителем, а первичная сущность.
Что для того, чтоб деньги имели смысл, должна быть система, которая бы обеспечивала право на присвоение чужого труда прямо пропорциональное их количеству и поциента. Она есть, но при капитализме поциенты-то хитрые, и решили — а нафига вообще выходить за предел слоя «деньги», можно замыкать их сами в себе, ведь целевая функция — присвоить себе больше оных, а для этого и потребители-то незачем, когда можно делать их из самих себя при помощи законов функционирования финансовой системы, «швабод договора» там всяких…
Но только вот потреблять они все будут реальные ресурсы, а не жевать свои купюры или пластик (которые, кстати, тоже кому-то надо реально произвести). таким образом увеличивая нагрузку на производителей.
Нет, я не против того факта, что в сложной системе с подобным методом разрыва зависимостей сама финансовая система должна производить какой-то отбор мощности на свое существование. Но уровень зарплаты бухгалтера А.И. Корейко в 46 рублей считаю здесь как раз приемлемым вознаграждением, а вот практически легализовавшиеся при капитализме «закрома» оного же деятеля — это необоснованная нагрузка на созидателей.
Если говорить кодерской аналогией, то использовали бы вы, например, какой-нибудь DI контейнер в своем приложении, а он, вместо исполнения своей утилитарной функции и (разумеется) отжирания небольшого ресурса, начал бы вам там биткойны майнить сам в себе, а все ваши приложения бы не получали ресурсов и висли. Выкинули бы вы такой контейнер козе в трещину и написали свой попроще, или вовсе обошлись бы без него, или продолжали бы свято быть уверенным, что контейнер — это первично, и его выкинуть было бы крамольной мыслью, пусть он жрет все больше и больше ресурсов, совершенно неадекватных тому, что требуются на его непосредственные функции, ведь он — основа приложения, а не вспомогательное звено?
Финансовые институты занимают небольшую долю в ВВП и основной положительный эффект от их работы — эффективное распределение ресурсов экономики. Других путей человечеству неизвестно, так что ваше мнение о справедливых зарплатах финансистов (не таких уж больших) никому неинтересно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А есть какие-то объективные ценности?
Так вроде все вокруг состоит из них. Начиная от табуретки (в случае меня) или офисного кресла (в случае вас), на которых мы вотпрямщас сидим, и электронно-вычислительного компьютера, на котором сейчас пишем. Все эти объективные ценности должны быть произведены и добыты, но почему-то все считают, что они получаются из денег почти что напрямую, а не путем многого числа разноплановых специалистов, которые за эти деньги должны выполнять свою работу. Наверное, потому что лузеры и не смогли освоить курсы «начни зарабатывать уже сегодня».
НЛО прилетело и опубликовало эту надпись здесь
То есть зарплата А.И.Корейко (и всех остальных заодно, чего уж там) должна определяться не объективными законами рынка на основе свободного обмена
А ничего, уважаемый Егор Тимурович, что «законы рынка на основе свободного обмена» — такая же утопия, как «каждому по потребностям, от каждого по возможностям» aka коммунизм? Только ежу непонятно, что одеяло на себя будет нехило так потянуто теми, кто осуществляет, контролирует и организует этот самый «свободный обмен», как только он перестанет быть бартерным? Что мы и наблюдаем в окружающей действительности.
НЛО прилетело и опубликовало эту надпись здесь
Вы таки не поверите, но Spring довольно популярен.
а что, он немерянно отжирает?
почему ж, поверю вполне охотно. я оным не пользовался (в анамнезе из аналогов только «самотык» (auto
только почему-то одна из таких же умных американских аббревиатур — KISS (keep it simple, stupid) совершенно забыта и выброшена из моды, и даже упоминание сего принципа в современной кодерской среде заносит вас в ряды маргиналов.
только почему-то одна из таких же умных американских аббревиатур — KISS (keep it simple, stupid) совершенно забыта и выброшена из моды, и даже упоминание сего принципа в современной кодерской среде заносит вас в ряды маргиналов.
Потому что она очень сложная. Вам нужно реально понимать что в вашей системе должно быть простым, а что — нет. Причем вы то может и дофига умный и понимаете, а понимает ли бизнес, какая система ему нужна?
А ирония в том, что полностью построенная система на том же Spring является довольно гибкой и позволяет гораздно проше решать проблему "ой, а тут надо расширить функционал".
довольно гибкой и позволяет гораздно проше решать проблему «ой, а тут надо расширить функционал».
почему-то весь мой реальный (не претендую, что крутой и на крутых проектах) опыт показывает, что основной довод пособников сложных архитектурных решений "а вот вдруг надо будет расширять, изменять и вдруг другая база, другому клиенту втюхнем то же решение" и потому давайте наплодим лишних новомодных абстракций" на деле оборачивается тем, что для любого сколь-либо серьезного нового функционала надо все равно достаточно перекроить приложение, и уж подавно в реальных приложениях бредовой является идея seamlessly, так сказать, заменить какой-нибудь слой. Ту же БД, например — все равно, сколько репозиториев, интерфейсов или микросервисов ни плоди, все равно все будет так или иначе завязано под особенности конкретной базы, структуры или сервиса. Да и полное переписывание приложения случается чаще, нежели надобность
Вы немного неправильно понимаете необходимость гибкости и абстракций. Разумеется при необходимости серьезной модификации приложения, в особенности которую вы не предусмотрели, у вас будет необходимость все переделать, но если вы все сделали правильно, при необходимости доработки или изменения бизнес-логики приложения, у вас затраты будут минимальные.
Типичный пример, вместо того, что бы жестко в коде зашивать отправку СМС с какого-то одного провайдера, сделать абстракного провайдера и подтягивать конкретную реализацию из конфига. И поверьте, если правильно собрать подмножество методов, которые предоставляют основные провайдеры, то это сработает (мое приложение так работает).
Касательно БД — это всегда вопросы про trade-off, разумеется, привязка к конкретным функциям БД делает все производительнее и круче, но скажем, используя django ORM и не используя extras или raw sql, у вас все вполне будет переносимо с postgres на mysql.
Я вот умудрился подобрать подмножество операций для настолько разных БД (RethinkDB, CouchDB, Unqlite) в своей ORM, что тесты написанные чисто на ORM отлично проходят на всех трех БД (пруф). И да, на работе я использую это чудо в каких-то не сильно важных сервисах :)
НЛО прилетело и опубликовало эту надпись здесь
fillpackart
В середине 70-х прошлого века — когда писали на ЯМБ (язык машин бухгалтерских) печатая программы на телетайпе ЭВМ «Наири-2»?
В конце 70-х прошлого века — когда вызывали «Джина» на БЕСМ-6 чтобы скормить ему программу на Фортране?
В середине 80-х прошлого века — когда запускали колоду перфокарт на PL-1 через устройство ввода перфокарт «EС-ЭВМ»?
В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
В начале 90-х прошлого века — когда переписали всё что было на Foxpro и Clipper?
В середине 90-х прошлого века — когда таскали «мышой на форму» в Дельфи?
В конце 90-х прошлого века — когда «писали классами» Java, от радости как кипятком?
В середине 00-х — когда вовсю использовали Mysql?
В середине 10-х — когда освоили jQuery и страницы веба ожили?
Или в настоящее время — когда все перешли на JavaScript, шуганув оставшихся по нишам?
Год, назовите fillpackart год? (С)
Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.Раньше? — Это когда?
В середине 70-х прошлого века — когда писали на ЯМБ (язык машин бухгалтерских) печатая программы на телетайпе ЭВМ «Наири-2»?
В конце 70-х прошлого века — когда вызывали «Джина» на БЕСМ-6 чтобы скормить ему программу на Фортране?
В середине 80-х прошлого века — когда запускали колоду перфокарт на PL-1 через устройство ввода перфокарт «EС-ЭВМ»?
В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
В начале 90-х прошлого века — когда переписали всё что было на Foxpro и Clipper?
В середине 90-х прошлого века — когда таскали «мышой на форму» в Дельфи?
В конце 90-х прошлого века — когда «писали классами» Java, от радости как кипятком?
В середине 00-х — когда вовсю использовали Mysql?
В середине 10-х — когда освоили jQuery и страницы веба ожили?
Или в настоящее время — когда все перешли на JavaScript, шуганув оставшихся по нишам?
Год, назовите fillpackart год? (С)
Протестую! Где вижуал бейсик? зы: про клиппер прочитал, всплакнул
Я кажется знаю когда, у меня дядя оттуда. Он люто программировал все что под руку попадется (компьютеры типа ZX80, калькуляторы, контроллеры различные, он сделал принтер из маханической печатной машинкив 85 году) и считал и до сих пор считает что программист не программист если он не знает ассемблера. Его время было наверное 70-80ые, так сказать расцвет компьютерной мысли.
Я до сих пор испытываю трепет и уважение перед людьми кто могут писать на ассемблере.
Наверное есть в этом все-таки часть правды. Но с другой стороны скорость разработки несопоставима. То что можно написать на JavaScript за день и то что можно написать на ASM за день — это же как современный телевизор сравнивать с наскальными рисунками, с точки зрения функциональности и пользователя. Для каждого языка и инструманта есть свои задачи.
Я до сих пор испытываю трепет и уважение перед людьми кто могут писать на ассемблере.
Наверное есть в этом все-таки часть правды. Но с другой стороны скорость разработки несопоставима. То что можно написать на JavaScript за день и то что можно написать на ASM за день — это же как современный телевизор сравнивать с наскальными рисунками, с точки зрения функциональности и пользователя. Для каждого языка и инструманта есть свои задачи.
Дело не в ассемблере (ничего особенно сложного там нет), дело в библиотеках. Современное программирование состоит в основном из обращений к библиотекам.
А те времена характеризовались тем, что программист был один на один с ЭВМ. Пустой. Не только среды разработки или компилятора, нет ни одной команды, кроме тех, что напишешь сам. Отсюда и ощущение, что скорость программирования на ассемблере отличается на порядки.
А те времена характеризовались тем, что программист был один на один с ЭВМ. Пустой. Не только среды разработки или компилятора, нет ни одной команды, кроме тех, что напишешь сам. Отсюда и ощущение, что скорость программирования на ассемблере отличается на порядки.
Не хочется долго спорить долго, поскольку и я не готов и возможно правда где-то посередине. Но с ходу у меня есть очень много возражений на безапелляционное:
Да библиотеки очень важны. Но разработка на острие ножа — она как раз менне всего завязана на библиотеки. И самое интересное создается скажем так «создателями библиотек».
Современное программирование состоит в основном из обращений к библиотекам.
Да библиотеки очень важны. Но разработка на острие ножа — она как раз менне всего завязана на библиотеки. И самое интересное создается скажем так «создателями библиотек».
Транслятор Фортрана заменял каждый оператор вызовом процедуры :)
Попробуйте посмотреть количество инструкций CALL в коде, который пишете «без использования библиотек». Проблема работы на ассемблере была в том, что прежде чем написать CALL, нужно было самому создать процедуру. Поэтому получалось так медленно. Когда речь пошла о создании ассемблерных вставок в код на Паскале ради выигрыша в скорости, трудозатраты оказались совсем не так велики.
Попробуйте посмотреть количество инструкций CALL в коде, который пишете «без использования библиотек». Проблема работы на ассемблере была в том, что прежде чем написать CALL, нужно было самому создать процедуру. Поэтому получалось так медленно. Когда речь пошла о создании ассемблерных вставок в код на Паскале ради выигрыша в скорости, трудозатраты оказались совсем не так велики.
Я первый раз столкнулся с подобным текстом 50 лет назад. Тогда появилось структурное программирование и из языков изгоняли GOTO. И программисты доказывали что три варианта цикла и два варианта ветвления слишком мало и есть случаи, когда при помощи GOTO можно сэкономить десяток тактов процессора. И таки выбили себе аварийный выход из цикла и из процедуры. Но в переходах в произвольную точку кода им было решительно отказано.
Это «убило творчество», но резко повысило надежность программ.
Это «убило творчество», но резко повысило надежность программ.
В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
Adabas это 70-е а Natural начало 80-х. Мы как раз недавно завершили проект по миграции софта, который работал с начала 80-х на мейнфрейме. Пришлось покопаться в коде на Natural для Adabas. В те времена это было круто, сейчас смотрится ужасно.
Интересен сдвиг восприятия — с одной стороны, в то время софт был написан быстрее и много меньшим количеством людей, чем мы потратили сейчас. С другой — просто реплицировать то, что было сделано тогда, сейчас таки можно сделать гораздо быстрее.
Раньше? — Это когда?
А ответ простой, и он не в языках и технологиях, а в доступности.
Раньше — это когда надо было выбивать себе в ВЦ «машинное время», и среднему обывателю недоступно было ничего, кроме калькулятора (непрограммируемого, само собой) за половину средней зарплаты.
А теперь — это когда вы работаете на инструменте, который есть у каждого. Поэтому и шарм с романтикой такой работы девальвирован чуть более, чем полностью. Только высокий спрос на поделки (ввиду огромного их количества) держит и соотношение порог_вхождения/выхлоп (доход) достаточно высоким, чтоб в кодерство шли все,
i0000
Lissov
sergeperovsky
dzsysop
dzsysopлома и какой-то суммирования и сдвига и писали программы прямо в кодах , программы для обслуживания интерактивного размещения (на французских мини ЭВМ реализованного) контактных площадок при производстве микросборок. Зеленоград. Далёкие годы.
tuxi
А Clipper — это конечно супер. Ты, типа как-бы С-программист и пишешь прогу которая не только с базой работает (22 секунды на выдачу зарплаты кассиром — сравнимо с банкоматом, поди — и кассир без всякой мыши не задумываясь по клавишам лупит то!) но и компилируется в один экзешник то! В один экзешник! Эх.
На тех же кто в те времена писал на Clarion, смотрели как сейчас на «несчастных пхпистов», наверное.
А ответ простой, и он не в языках и технологиях, а в доступности.Вряд ли fillpackart имел такие допотопные времена когда не был доступен программируемый калькулятор. А имея программируемый калькулятор ты уже был явно программистом.
Lissov
Adabas это 70-е а Natural начало 80-х. Мы как раз недавно завершили проект по миграции софта, который работал с начала 80-х на мейнфрейме.Ну, к нам в Минск, на завод выпускавший роботов (да, было дело тогда) Adabas в виде «ДИСОД» пришёл попозже. Ну, как пришёл? — из Москвы на ленте привезли. ;-)
sergeperovsky
Я первый раз столкнулся с подобным текстом 50 лет назад. Тогда появилось структурное программирование и из языков изгоняли GOTO.Те "бои за изгнание goto" были конечно эпические. Хотя не такие как теперешние "ООП против Функционального".
dzsysop
Я кажется знаю когда, у меня дядя оттуда. Он люто программировал все что под руку попадется (компьютеры типа ZX80, калькуляторы, контроллеры различные, он сделал принтер из маханической печатной машинкив 85 году) и считал и до сих пор считает что программист не программист если он не знает ассемблера. Его время было наверное 70-80ые, так сказать расцвет компьютерной мысли.Хм, тогда инженер за кульманом с логарифмической линейкой в нагрудном кармане — это расцвет конструирования!!! Поди. ;-)
dzsysop
Я до сих пор испытываю трепет и уважение перед людьми кто могут писать на ассемблере.Когда я явился в отдел и показал начальнику отдела блок-схему алгоритма, он оценил, но сказал что ассемблер они выкинули из-за того что супервизор, где сидел его (ассемблера) обработчик, занимал слишком много памяти в мини-компьютере, поэтому умножения у них в системе не реализовано и программируют они в… кодах. Так, с помощью
tuxi
Протестую! Где вижуал бейсик? зы: про клиппер прочитал, всплакнулвижуал бейсик? — Да, слона то я и не приметил. Но не обессудьте, с бейсиком сталкивался только в Excel.
А Clipper — это конечно супер. Ты, типа как-бы С-программист и пишешь прогу которая не только с базой работает (22 секунды на выдачу зарплаты кассиром — сравнимо с банкоматом, поди — и кассир без всякой мыши не задумываясь по клавишам лупит то!) но и компилируется в один экзешник то! В один экзешник! Эх.
На тех же кто в те времена писал на Clarion, смотрели как сейчас на «несчастных пхпистов», наверное.
Те «бои за изгнание goto» были конечно эпические. Хотя не такие как теперешние «ООП против Функционального».
«ООП против Функционального» это всего лишь о соответствии задачи и инструмента.
А изгнание goto в точности соответствует тому, о чем статья: программистов лишали СВОБОДЫ.
А изгнание goto в точности соответствует тому, о чем статья: программистов лишали СВОБОДЫ.Свободы? Хм, я помню эти программы насыщенные goto — проще было их все переписать, — чем разобраться в них и что-то поправить.
У меня есть замечательное воспоминание, один наш сотрудник на Фортране написал сложную расчетную программу и никак не мог ее отладить. Я посмотрел текст и посоветовал вставить в определенном месте «PRINT 3». Он долго недоумевал, зачем печатать константу. Но когда было напечатано «4» приходил в себя много дольше :)
Свобода! Неосторожным движением можно переопределить константу.
Но ведь автор обсуждаемой статьи жалуется ровно на то же самое: написать программу на Go можно гораздо меньшим числом способов, чем на привычных ему языках. Безликий код. Никакой свободы. Убивают творчество. Нужно противостоять. Я сомневаюсь, что нужно. Слишком хорошо помню что бывает от излишней свободы.
Свобода! Неосторожным движением можно переопределить константу.
Но ведь автор обсуждаемой статьи жалуется ровно на то же самое: написать программу на Go можно гораздо меньшим числом способов, чем на привычных ему языках. Безликий код. Никакой свободы. Убивают творчество. Нужно противостоять. Я сомневаюсь, что нужно. Слишком хорошо помню что бывает от излишней свободы.
хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности
Мне кажется вы немного путаете понятия сложности самой системы (которая с одной стороны как раз вредит надежности, так как чем больше механизмов в устройстве или кода в программе — тем потенциально больше проблем можем с этим возникнуть) и сложности при разработке и поддержке этой системы. Да, сейчас школьник может написать программу для смартфона по распознавания текста на фотографии, не умея даже собственного сервера и никакого опыта в машинном обучении, просто повторив туториал по какому-нибудь TensorFlow.
Сложнее всего ведь создавать простые вещи, которые будут работать и быть надежными, потому что они простые.
Go или Rust или другие языки связывают руки программисту, не давая выстрелить в ногу, в то время как на C/С++ вы вольны это сделать. Но попробуйте сейчас написать json-парсер или http-сервер на C. Вам точно пригодится высшее образование. На go это сделать проще и благодаря этому мы можем строить бóльшие и более сложные системы, которые будут кроме этого надёжны и просты в поддержке.
Кажется, будто из-за этого профессионала с годами стажа может заменить выпускник университета, но это не совсем так. У профессионала есть опыт, просто раньше это опыт, условно — искать глазами в коде возможные разыменования nil-ов (зачем эти ваши новомодные статические анализаторы, ими только новички пользуются, а я ведь профессионал!), а теперь это опыт другого характера — пусть даже написать на вечер сервис, на который раньше была нужна команда программистов и месяцы работы.
вспоминаю свое прошлое…
изучение было с С, потом С++, потом Java…
сейчас в основом Haskell, все хорошо.
Было время когда я почти полгода рефакторил проект, просто пипец был лютейщий… ад.
Пытался привести это в порядок и оставить после себя читаемый код.
Потом я уже писал свой код и вроде доработки после меня шли нормально, ну я надеюсь))
Потом попался код как в первом случае… о боже я тяжело его воспринимал, вспоминая как я легко читал бредятину из первого случая, просто тогда я привык.
Вопрос на засыпку, а писать легко читаемый код это не искусство случаем?
изучение было с С, потом С++, потом Java…
сейчас в основом Haskell, все хорошо.
Было время когда я почти полгода рефакторил проект, просто пипец был лютейщий… ад.
Пытался привести это в порядок и оставить после себя читаемый код.
Потом я уже писал свой код и вроде доработки после меня шли нормально, ну я надеюсь))
Потом попался код как в первом случае… о боже я тяжело его воспринимал, вспоминая как я легко читал бредятину из первого случая, просто тогда я привык.
Вопрос на засыпку, а писать легко читаемый код это не искусство случаем?
Почему-то после прочтения осталось послевкусие «Автостопом по галлактике» и очень близко промелькнула мысль, что это путь Воганов.
Когда-то все программисты были учеными. Все делалось впервые, не было никаких методик, приходилось изобретать.
Потом появились программисты — инженеры. Они осваивали методики, делали в соответствии с ними инструменты и ими пользовались.
Потом пришли программисты — рабочие. Кодеры пользуются чужими инструментами. Им не известны принципы их работы, но это и не нужно — им достаточно инструкции. И они составляют подавляющую часть программистов.
Ученые и инженеры никуда не делись. И меньше их не стало. Но в общей массе программистов их не видно.
Хотите творчества? Добро пожаловать в разработку уникальных вещей. Прежде всего — нового инструментария. Встали к станку? Не нужно возмущаться, что нужно гнать продукцию по чертежам с точным соблюдением технологии.
Потом появились программисты — инженеры. Они осваивали методики, делали в соответствии с ними инструменты и ими пользовались.
Потом пришли программисты — рабочие. Кодеры пользуются чужими инструментами. Им не известны принципы их работы, но это и не нужно — им достаточно инструкции. И они составляют подавляющую часть программистов.
Ученые и инженеры никуда не делись. И меньше их не стало. Но в общей массе программистов их не видно.
Хотите творчества? Добро пожаловать в разработку уникальных вещей. Прежде всего — нового инструментария. Встали к станку? Не нужно возмущаться, что нужно гнать продукцию по чертежам с точным соблюдением технологии.
Потом пришли программисты — рабочие.… Им не известны принципы их работыОбобщаете? Вероятно, вы хотели сказать "им необязательно знать принципы их работы".
нужно гнать продукцию по чертежам с точным соблюдением технологииМало такого в программировании, по-моему. Ни инженеров в стереотипном виде с готовыми метриками и требованиями (кроме узких областей), ни рабочих, выдающих продукцию по чертежам. Какие чертежи при автоматизации бизнес-процессов и прочего? Сначала изучение и анализ области, потом попытка формализации процессов в более менее читаемом виде вкупе с построением работающей системы из доступных составляющих. И это при быстром изменении самого программирования.
Хотя можно рассматривать понятие «инженер» шире (есть даже официальный общеупотребимый термин software engineering), но если не хочется, то необязательно натягивать эти «заводские» рамки на программирование.
Вот типичная программа современного вузовского курса по специальности инженер-программист:
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, но нет реляционной алгебры.
Что-то раскажут про ООП, но нет теории конечных автоматов.
Сотни часов на обучение конкретным инструментам. Но подсчитать алгоритмическую сложность не умеем.
Я уже не говорю о том, что ни про логическое, ни про функциональное программирование студентам вообще не упомянут.
«Позабудте индукцию и дедукцию — давайте продукцию».
Что же говорить о всевозможных курсах «программист за два месяца».
«Сначала изучение и анализ области, потом попытка формализации процессов в более менее читаемом виде вкупе с построением работающей системы из доступных составляющих.»
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистов. А чаще уже не приходит — удается обойтись подбором и настройкой готовой системы.
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, но нет реляционной алгебры.
Что-то раскажут про ООП, но нет теории конечных автоматов.
Сотни часов на обучение конкретным инструментам. Но подсчитать алгоритмическую сложность не умеем.
Я уже не говорю о том, что ни про логическое, ни про функциональное программирование студентам вообще не упомянут.
«Позабудте индукцию и дедукцию — давайте продукцию».
Что же говорить о всевозможных курсах «программист за два месяца».
«Сначала изучение и анализ области, потом попытка формализации процессов в более менее читаемом виде вкупе с построением работающей системы из доступных составляющих.»
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистов. А чаще уже не приходит — удается обойтись подбором и настройкой готовой системы.
Вот типичная программа современного вузовского курса по специальности инженер-программистНе могу согласиться с вашим резюме по образованию инженера-программиста. У нас было многое базовое из того, что вы полагаете отсутствующим, и кое-что неупомянутое вами, и меньше инструментов (у вас аж 4 языка изучается, неужели такое где-то есть?). Могу согласиться с тем, что в работе требуется намного меньше, чем изучается, и с низким уровнем кадров в постсоветском образовании (некоторые предметы некому вести).
Разработка реляционных баз данных в MS SQL Server 2012. Язык запросов Transact-SQLОбычно курс разделен на несколько частей. Вот на примере, типичный предмет: на лекциях проходится в каком-нибудь виде реляционная алгебра, на практике какая-нибудь РСУБД.
UML. Технология программирования и моделирования программных системСамый близкий к стереотипичной инженерии курс, по-моему, и реже всего используемый в работе до уровня сеньора. Наверно, из-за незрелости индустрии программирования.
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистовЭто часть профессиональных обязанностей инженера-программиста. В очень крупных проектах выделяются аналитики, чья единственная работа — анализ бизнеса, но в своих поддоменах программистам приходится разбираться — аналитики не выдают алгоритмы, они тоже довольно обобщенно описывают среду. Единственное формальное описание процессов — это код. В некрупных проектах программисты зачастую — единственные аналитики, которые разговаривают с бизнесом.
Я сам так когда-то работал, выполняя функции бизнес-консультанта, бизнес-аналитика, постановщика задач и программиста. Вдвоем с программистом-тестером мы поднимали большие по тем временам задачи.
Но когда я сейчас прихожу в организацию и провожу анализ, мне не приходит в голову писать что-то серьезное самому. Я говорю: вам подходит вот такая система, при правильной настройке она покроет все ваши задачи. Вряд ли описание бизнес-процессов в специализированной среде можно назвать программированием.
А промышленные системы пишут крупные команды с очень четким разделением функций. Кустарь-одиночка не может с ними тягаться.
Впрочем, одну такую команду я и сейчас знаю. Два доктора наук ведут разработку в своей области более тридцати лет. Программисты они так себе, но суть проблемы и математический аппарат понимают настолько глубоко, что развитие продукта идет удивительными темпами. Пользователи уверены, что работает команда человек в тридцать. но это все-же «уходящая натура». Реликт времен, когда каждый программист был ученым или по крайней мере инженером.
Но когда я сейчас прихожу в организацию и провожу анализ, мне не приходит в голову писать что-то серьезное самому. Я говорю: вам подходит вот такая система, при правильной настройке она покроет все ваши задачи. Вряд ли описание бизнес-процессов в специализированной среде можно назвать программированием.
А промышленные системы пишут крупные команды с очень четким разделением функций. Кустарь-одиночка не может с ними тягаться.
Впрочем, одну такую команду я и сейчас знаю. Два доктора наук ведут разработку в своей области более тридцати лет. Программисты они так себе, но суть проблемы и математический аппарат понимают настолько глубоко, что развитие продукта идет удивительными темпами. Пользователи уверены, что работает команда человек в тридцать. но это все-же «уходящая натура». Реликт времен, когда каждый программист был ученым или по крайней мере инженером.
У меня все то, о чем вы говорите, было в ВУЗе. И комбинаторика, и теория графов, и теория конечных автоматов. Так что с «типичностью» вашего списка не соглашусь.
У меня тоже. Но это было очень давно. Я говорю о тенденции. Большинство современных программистов в крупных коммерческих проектах работают по очень узкой специализации: переводят спецификации в конкретный язык программирования.
Это действительно рабочие: знать устройство своего «станка» не требуется, только органы управления; подбирать «режимы резания» не нужно — все есть в «технологической карте». И с точки зрения организации крупного производства это правильно.
Это действительно рабочие: знать устройство своего «станка» не требуется, только органы управления; подбирать «режимы резания» не нужно — все есть в «технологической карте». И с точки зрения организации крупного производства это правильно.
Тоесть предлагается организовать — что? Ковен магов?
Ну вот выделится какое-то количество некомерческих программистов. Что случится с коммерческими?
Ну вот выделится какое-то количество некомерческих программистов. Что случится с коммерческими?
НЛО прилетело и опубликовало эту надпись здесь
Когда я читаю что-то вроде «должны быть» или «должно быть», мне хочется взяться за револьвер ржать. Кто будет определять это долженствование и соответствие ему? Кто сказал, что это конекретное «должны» лучше чьего-то другого «должны», где говорится абсолютно обратное? Никто и ничто никому и ничему не должно. Все должен определять свободный рынок, а для стратегических/оборонных областей — госзаказы с открытым и прозрачным конкурсом. Все.
НЛО прилетело и опубликовало эту надпись здесь
У вас как у бизнеса всегда остаётся опция нанимать только топовых программистов для разработки очередного офисного пакета или даже какой-нибудь AAA-игры (очень крупные проекты).
От самолетов и домов зависят жизни, в любых таких областях строгая регуляция. Но IT в основном состоит из менее критичных областей. На плохом самолете летать страшно, поэтому я буду платить много за гарантии, а пользоваться забагованным текстовым редактором — нет, за отсутствие багов я много не заплачу. Вполне свободный рынок.
От самолетов и домов зависят жизни, в любых таких областях строгая регуляция. Но IT в основном состоит из менее критичных областей. На плохом самолете летать страшно, поэтому я буду платить много за гарантии, а пользоваться забагованным текстовым редактором — нет, за отсутствие багов я много не заплачу. Вполне свободный рынок.
Вот именно рынок и выбирает лучшие самолёты и классные дома.
1. Высококлассные спецы должны создавать тулзы для построения систем. Их нужно мало и они должны быть очень тщательно спроектированы.Любопытно. А в вашем идеальном мире только программисты должны быть высококлассными, или вообще все специалисты? Что остальным делать, кто не стал высококлассным?
2. А вот пользоваться этими тулзами должны специалисты в предметных областях в декларативном стиле.
Нужно понимать, что ИТ — это инфраструктура цивилизации. И основание её на бизнес интересах до добра не доведёт.В СССР IT было вспомогательным инструментом народного хозяйства, что по сути то же самое, что и интересы бизнеса. Что капиталистический, что социалистический директор будут подпинывать программиста закончить автоматизацию. А на чем базируется IT в вашем мире?
«чтобы программированием могли заниматься только некоммерческие организации»… «сделал бы порог входа как можно боллее высоким»…
— вот по таким же критериям когда-то жрецы и попы сохраняли письменность и все знания о мире только для себя — не для быдла такие сокровенные и сложные знания! И таки им удалось затормозить развитие человечества на века. ))
— вот по таким же критериям когда-то жрецы и попы сохраняли письменность и все знания о мире только для себя — не для быдла такие сокровенные и сложные знания! И таки им удалось затормозить развитие человечества на века. ))
Просто иногда надо вытаскивать нос из редактора. Жизнь — это не только программирование.
Идём свергать власть!
Достаём Ленина из саркофага, покупаем броневик…
Короче строим коммунизм!
Ну и я не вижу в этом проблемы. Нормальные, творческие личности всегда востребованы обществом. Если бы их не было, то мы вряд ли бы выбрались из каменного века.
Достаём Ленина из саркофага, покупаем броневик…
Короче строим коммунизм!
Ну и я не вижу в этом проблемы. Нормальные, творческие личности всегда востребованы обществом. Если бы их не было, то мы вряд ли бы выбрались из каменного века.
Нормальные, творческие личности всегда востребованы обществом.Это неверно.
Тут много вопросов:
— что такое «нормальные» — это какие? — больше зарабатывающие?
— что такое «творческие личности»? — которые творят что-то новое и неважно что это новое вредно, никому не нужно, никому сейчас не нужно, неизвестно нужно ли вообще, неизвестно нужно ли будет вообще и с какой целью (вредной, нейтральной или критической спасительной?)
— всегда востребованы обществом? — Полно примеров в истории, когда творческий личностей общество гнобило вплоть до сжигании на костре. — Вам наверняка надо изменить тогда ваше определение:
Нормальные, творческие личности всегда востребованы нормальным прогрессивно-мыслящим обществом.
Но тогда вы должны будете определить что есть «нормальное прогрессивно-мыслящее общество» и есть ли это «общество потребления» — то есть общество «капиталистическое»?
Если вы глубоко и рекурсивно помыслите — то вы придёте к необходимости какой-то аксиомы в виде Нормы или Традиции (то есть Веры, она же породит Религию, разговоры о которой гнобимы на Хабре).
Капитализм основан на старой аксиоме — Нельзя закапывать свой талант в землю ибо это грех. (С)
Все остальные рассуждения есть типа «теоремы», стоящие на этой аксиоме.
Однако, как только вы решите "проявить гордыню" и заявить во всеуслышание, что вы сами решаете что делать со своим талантом — закопать его или явить миру? — вы выбиваете эту аксиому из-под ног капитализма и «летите в пропасть» (или вы собираетесь эту аксиому чем-то заменить?)
А деньги? — чем мерить талант? — трудоднями? — почётными грамотами? — разрешением на выезд за границу? — процентом по кредиту? — путёвками в санаторий? — отрезом на костюм? — красными шароварами? — кармой? — лайками?
А нужно ли его мерить? — А как без меры явить его миру? — Ибо явление миру и есть… измерение! — Не так ли?
Что предлагает fillpackart? Он предлагает измерять путём создания нечто типа «закрытой академии программирования»:
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока.
Так поступали ранее (смотри первые Академии) и так поступили однажды… французы (смотри Пантеон куда они помещают ушедшие таланты свои) и так поступили математики (когда их труд отверг как полезный сам Нобель) введя свои премии и медаль.
Но когда уже есть всеобщий измеритель Таланта и это есть сам талант (то бишь деньги), то все эти измерители для сидящих в «высоких башнях из слоновой кости» похоже уже больше не нужны. Поди.
Вы описали частный случай общей филосовской проблемы: что первично, дух или материя. Все мы имеем стремления, т.е. «души прекрасные порывы», при этом мы отягощены плотью, её необходимостями и, как следствие постоянно идёт взаимная корректировка. Она вечна. Её ещё называют борьбой добра со злом.
Читал, что на одном из конкурсов дизайна выиграл рено логан — (первая версия рубленая такая), второе какой-то там ламборджини.
Из объяснения я понял, что он занял первое место, потому что каждая ее деталь штапуются одним ударом дешевого пресса из дешевого металла. В то время как для производства требуется ламбо, нужно очень сильно извращаться, и тогда ко мне пришло понимание, что творчество в простоте.
Знаете, сейчас еще в моде сейчас вручную рисовать фотореалистичные изображение, так вот это не творчество — это онанизм. Творчества и искусство — это двумя штрихами передать все эмоции, а не два месяца вырисовывать какую-то херь, которую можно одним нажатием кнопки сделать.
Втиснуть свой проект в примитивные простые паттерны, который каждый джун поймет, а не городить огород велосипедов на костылях, который можно понять только обладая 20 летним опытом в программировании — это и есть красивый код, а то что вы называете красивым кодом — это мастурбация.
Из объяснения я понял, что он занял первое место, потому что каждая ее деталь штапуются одним ударом дешевого пресса из дешевого металла. В то время как для производства требуется ламбо, нужно очень сильно извращаться, и тогда ко мне пришло понимание, что творчество в простоте.
Знаете, сейчас еще в моде сейчас вручную рисовать фотореалистичные изображение, так вот это не творчество — это онанизм. Творчества и искусство — это двумя штрихами передать все эмоции, а не два месяца вырисовывать какую-то херь, которую можно одним нажатием кнопки сделать.
Втиснуть свой проект в примитивные простые паттерны, который каждый джун поймет, а не городить огород велосипедов на костылях, который можно понять только обладая 20 летним опытом в программировании — это и есть красивый код, а то что вы называете красивым кодом — это мастурбация.
Вот зря убили Дельфи. Каждый программировал в индивидуальном стиле. Низкий порог входа. Но можно было запросто отличить код быдлокодера от нормального кода, нормальный от хорошего, а хороший от отличного — так что как Пётр I говорил — дурость каждого была видна.
Мир не идеален. Я тоже иногда так раскисаю, сижу вся в соплях и хочется к маме…
Все, что изложено, смело можно перенести из мира программирования на любую другую отрасль. Данная «проблема» не специфична для программирования. Вспоминаю высказывание кого-то из великих конструкторов: «я проектирую какие-то гребанные мосты, вместо того, чтобы заниматься серьезными научными проектами!».
Как большинство «проблем», эта — в голове, а не в мире. Проблема — это противоречие. В частности, идеализированные картинки (например, про «высокое программирование»), порожденные из наших личных предпочтений, против реальности.
Во-первых, нужно принять, что мир сейчас, в данный момент, устроен так, как он устроен. «То, что есть — есть. То, чего нет — нет.» Отрицание реальности служит плохую службу.
Во-вторых, нужно увидеть свое место в мире в данный момент, и сразу станет понятно, почему к нам предъявляют именно такие требования, какие предъявляют (можно будет перестать этому удивляться и ожидать чего-то другого). Страус не выживет в Антарктиде, а пингвин — не выживет в Сахаре. В коротком времени подсистемы определяются условиями надсистем.
После чего нужно самоопределиться: или я остаюсь здесь (и тогда бессмысленно на что-то жаловаться — просто будь тут и живи на 100%), или я проявлю активность по отношению к своей проблеме — например, иду в другое место, более соответствующее моим амбициям и ценностям (может, и найдешь), или я говорю, что возьму и изменю это место! Не так много вариантов: остаться (подварианты: продолжать ныть или полюбить то, что есть), уйти, изменить.
В последнем случае самое глупое — пытаться изменить сразу весь мир (это опять романтизм и идеализации), нужно найти маленькую-премаленькую область твоего окружения и попробовать изменить ее. Скорее всего это не получится (или получится, но не совсем то), но в процессе человек что-то понимает и еще меняется сам. А может, и получится, и тогда это заряжает на кратно большие усилия к изменениям.
Становясь многократно в активную позицию, меняя места обитания, и обламываясь о полу-успешные попытки изменения, принимая реальность, и где-то чуть-чуть меняя её (чаще всего все равно не так, как нам бы хотелось), мы растем и живем.
И со временем наши старые проблемы начинают видеться совсем с другой стороны, казаться смешными, трансформироваться в просто обстоятельства.
И это все вообще не о программировании.
Как большинство «проблем», эта — в голове, а не в мире. Проблема — это противоречие. В частности, идеализированные картинки (например, про «высокое программирование»), порожденные из наших личных предпочтений, против реальности.
Во-первых, нужно принять, что мир сейчас, в данный момент, устроен так, как он устроен. «То, что есть — есть. То, чего нет — нет.» Отрицание реальности служит плохую службу.
Во-вторых, нужно увидеть свое место в мире в данный момент, и сразу станет понятно, почему к нам предъявляют именно такие требования, какие предъявляют (можно будет перестать этому удивляться и ожидать чего-то другого). Страус не выживет в Антарктиде, а пингвин — не выживет в Сахаре. В коротком времени подсистемы определяются условиями надсистем.
После чего нужно самоопределиться: или я остаюсь здесь (и тогда бессмысленно на что-то жаловаться — просто будь тут и живи на 100%), или я проявлю активность по отношению к своей проблеме — например, иду в другое место, более соответствующее моим амбициям и ценностям (может, и найдешь), или я говорю, что возьму и изменю это место! Не так много вариантов: остаться (подварианты: продолжать ныть или полюбить то, что есть), уйти, изменить.
В последнем случае самое глупое — пытаться изменить сразу весь мир (это опять романтизм и идеализации), нужно найти маленькую-премаленькую область твоего окружения и попробовать изменить ее. Скорее всего это не получится (или получится, но не совсем то), но в процессе человек что-то понимает и еще меняется сам. А может, и получится, и тогда это заряжает на кратно большие усилия к изменениям.
Становясь многократно в активную позицию, меняя места обитания, и обламываясь о полу-успешные попытки изменения, принимая реальность, и где-то чуть-чуть меняя её (чаще всего все равно не так, как нам бы хотелось), мы растем и живем.
И со временем наши старые проблемы начинают видеться совсем с другой стороны, казаться смешными, трансформироваться в просто обстоятельства.
И это все вообще не о программировании.
Тони Хоар ещё в 1975 писал, что борьба с любителями избыточной сложности это будет долгий и нелегкий процесс, но вот такие посты прям показывают, что через 50 лет это не борьба, а война просто :)
Безликий код убьет программирование, и ничего мы с этим не сделаем