Комментарии 357
Программируя, я хочу заниматься творчеством.
Сорян, Бро. Все хотят (ну или когда-то хотели :)), согласен. Но это плохой путь. Разработчики в первую очередь нужны для того, чтобы делать какой-то продукт, который приносит деньги. И чем проще среда, тем продуктивнее будет разработчик (но, как говорил Великий, «Всё следует упрощать до тех пор, пока это возможно, но не более того.»). Чем больше кода можно написать достаточно эффективно и при этом стандартно — тем лучше. Поэтому решения типа Go и появляются — они отвечают современным требованиям серверной («микросервисной») разработки и облегчают написание таких программ. Никого не интересует творчество. Вернее интересует, но это лишь малая часть продукта. В основном нужно просто «прокопать от забора до обеда», и чем меньше усилий для этого нужно затратить, тем лучше, ИМХО.
Вообще не совсем понятно, по каким критериям судят о красоте кода: почему красивый код — это обязательно долго и дорого? Может быть подход, при котором получается долго и дорого, не так уж и красив на самом деле.
Забавно, но не то, чтобы сами компании до конца понимали, для чего нужны разработчики.
Вспомним, надавно прошедшую волну статей по собеседованиям, показавшую нам, что требования, взгляды и подход к самому приему на работу не только существенно различаются, но бывают ошибочны и вредны, вне зависимости от размера компании.
Также и с самой разработкой, с критериями оценки производительности.
Лично у меня недавно была ситуация: позвали в проект, существовавший без архитектора, поставили задачу оптимизации. После недельного аудита: готового набора текстов по архитектурным проблемам, гайдов по критическим проблемам команды( а у команды были весьма серьезные проблемы ), заявился владелец бизнеса и усевшись рядом с техдиром поинтересовался. — "а какой вы написали код? вы что, не работали все это время?!".
К огромному сожалению, руководителям часто интереснее, сколько раз вы ударили кувалдой, нежели, то, сколько труда вы приложили для понимания того, куда следует ударить. В долгосрочной перспективе, эти вещи становятся мелочами, но, проработав пару недель — спокойней отписать заявление.
Поэтому ничего с кодом не произойдет. В течение десятка лет появится автоматизация большинства задач линейных программистов, и перед ними станет выбор — либо переходить на новый уровень программирования и создавать сложный код с продуманной архитектурой (что получится мало у кого), либо идти в другие профессии. Потому что просто написание безликого кода станет ненужным.
неговнокодеров
С уставом и всё-такое
В других специальностях есть подобные институты
Будет, с одной стороны, такой знак качества, а с другой — хранители истинного духа и традиций
Как дети-индиго, только наоборот
С кодом всё точно так же. И ниши для штучного программирования и искусства всё равно всегда будут, только вот все в них не влезут.
Чужих — это тех, кто не отучился в соответствующих учебных заведениях?
Медицина в США — лучшая на планете
«Я тебе конечно верю, разве могут быть сомненья».
В контексте «лучшей медицины» я еще слышал про Израиль, Испанию, Британию и Канаду. Почему верить я должен именно вам?
А еще даже если вы выработаете критерий «лучшести» медицины и докажете, что она лучшая именно в США, вам также предстоит доказать, что закрытость — это именно причина топового места и медицина лучшая именно благодаря этому, а не вопреки.
Как и юристы.
Собственно все то же самое, просто замените медицину на юриспруденцию.
Некто Robert C. Martin похожему посвятил минимум одну книгу. Получилось максимально уныло, с кучей нравоучений. К сожалению, ее иногда спрашивают ашары.
Надо создать профессиональную ассоциацию программеровсепия-старцы?)
Как дети-индиго, только наоборот
Если сравнить с stl от c++ это просто небо и земля. Там хоть и исходники доступны, но понять что же все-таки происходит. Надо как-то понять в каком месте какого шаблонного класса объявлен какой тип и в каком шаблоне он используется и зачем. Вместо объявления интерфейса и требования соблюдения этого интерфейса есть привязка к именам типов и методов и это так усложняет понимание кода, что надо гораздо больше времени чтоб вникнуть. Не говоря уже о том чтобы скопировать увиденный подход к себе в приложение. И вот в чем проблема когда задачу можно решить 15ю способами одна и та же проблема в разных местах приложения будет решена по-разному. Часть из этих решений будет простыми и неправильными. А это уже ведет к разному поведению и такие куски кода может быть тяжело заметить, чтобы свести к общим функциям.
С тех пор я перешел сначала на Haskell, потом на Scala, и что бы разобраться в библиотеке часто достаточно посмотреть ее интерфейс, даже не документацию. Я этим очень доволен.
Впрочем, в обоих случаях непонятно, для чего это может потребоваться, и каким образом это может зависеть от языка.
Система типов не достаточно выразительная, что бы полноценно описать интерфейс.
Сравнивать надо не с ними, а с академическими Haskell и SML, и с современным, вобравшим лучшие практики Rust.
Что программируете? Почему не можете это сделать работой?
Главное, чтобы не вместо.
Можно и нужно смешивать хобби и работу
особенно когда работа — большая часть жизни
Как раз наоборот. Если работа — большая часть жизни, то тратить что-то от оставшейся части на ту же работу — не лучшее решение. Я бы сказал, что это просто преступно по отношению к себе.
А для того, чтобы получать удовольствие от работы, не обязательно заниматься этой же работой в качестве хобби.
Для начала нужно разобраться, что такое работа. И что такое хобби. И причем тут связь с удовольствием.
Для начала нужно разобраться, что такое работа. И что такое хобби.
Работа — основной источник дохода. Хобби — деятельность, которой человеку нравится заниматься во время, свободное от работы.
И причем тут связь с удовольствием.
Это тема обсуждения в данной ветке, очевидно.
Тогда все становится еще более запутанным. Получается, что вы не хотите, чтобы интересное занятие приносило доход. И не хотите, чтобы нравилось то, чем вы занимаетесь на работе.
Мне не понятна эта связь, учитывая, что эти концепции искусственны сами по себе. Нет в биологическом мире разницы между "работой" и "хобби". Вам не кажется, что вы просто занимаетесь чем-то не тем?
Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаково плохо
Fixed.
Я, как и большинство инженеров, верю, что творю великие вещи.
Такие штуки как docker, kubernetes не достаточно великие вещи? Восхищаются готовым продуктом(nginx, postgresql, mysql и т.д.), а не его исходным кодом.
«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. Еди
Перефразируя известную фразу Филиппа Гринспена: "Каждая достаточно сложная программа на Go содержит узкоспециализированную, недокументированную, забагованную и тормознутую реализацию половины CommonLisp"
Рефлексию в Go не рекомендуют использовать без крайней необходимости и неспроста (при этом буквально все используют библиотеки, которые пропитаны ей как бисквит коньяком: encoding/json, gorilla/schema и пр.). Лучше уж нормальная динамическая типизация.
В вас и видно, что в вас говорит бывший фанат, который обиделся на что-то. Язык общего назначения был и остался. Кубернетис так и остается отличным примером, что язык применяется и тянет на себе целую индустрию, индустрию контейнеров, т.к. буквально все проекты в ней написаны на Go.
Рефлексию не рекомендуют по другой причине, озадачились бы узнать, прежде чем заявлять что-то. Причина всегда была и есть одна — пакет рефлексий сложен в работе, имеет много подводных камней и неочевидностей, поэтому можно натворить дел. Поэтому не рекомендуют туда лезть всем подряд, а только тем, кто разбирается. Рефлексия сложна по определению. И в стандартной библиотеке он, потому что он нужен и огромное количество библиотек его применяющих лишнее доказательство, что он нужен. По этой же причине рефлексию все пытаются добавить в плюсы.
а обобщенное программирование это глава в спецификации языка.
Полиморфизм — он и в Африке полиморфизм. Если человек знает теорию типов, свойства соответствующих систем, их влияние друг на друга — на просмотр и осознание этой главы уйдет порядка нескольких минут. Ну а если он необразован — его проблема.
А другое требует очень больших усилий в грамотном дизайне, рассмотрении всех ситуаций, взаимодействия со всеми остальными фичами языка.
То есть разработчики просто поленились?
Надеюсь Geth таким же прорывом Go не считают? А то у меня от этого продукта регулярно болит на работе.
Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
То, что в статье названо "реализацией дженериков", не очень похоже на них. Примеры того, где это используется (опять же, в статье), относятся к сериализации/десериализации объектов. Это чисто ран-тайм операция, дженерики ее не решают.
Без дополнительной аргументации и приведения конкретных примеров лично мне совсем неочевидно, что автор той статьи прав, говоря, что kubernetes пострадали от отсутствия дженериков и реализовали их заменитель.
Я вот тоже прочитал статью по вашей ссылке, полистал комментарии к ней.
То, что в статье названо "реализацией дженериков", не очень похоже на них.
Чтобы реализовать генерики, надо патчить компилятор, очевидно. Тут правильнее было сказать не "реализация генериков", а "замена генериков", то есть, при наличии генериков воротить все эти рантайм-забавы бы не пришлось, при этом код был бы более надежен (т.к. фиксировались бы конкретные типы, вместо просто RuntimeObject).
Это чисто ран-тайм операция, дженерики ее не решают.
Дженерики решают то, что после десереализации у вас получится не объект типа Hz4e, а нормальный конкретный тип, с которым вы сможете полноценно работать.
А можете привести пример, как подход, реализованный kubernetes, можно было бы заменить на дженерик для какого-то из имеющихся сценариев использования?
В оригинальной статье этого нет — поэтому выглядит голословно. Но возможно, все так есть, просто автор решил опустить несущественные детали?
Десериализация посредством generic методов + рефлексии позволяет на выходе получить результирующий тип, а не его динамическое представление.
Типа var descriptor = getObject().
- А где тут дженерик?
- Какая из проблем, которые решали создатели kubernetes, решена тут более изящно?
UPD: сорри, не заметил второго коммента :)
В общем, это все здорово, но в принципе мало отличается от вызовов в коде kubernetes. Например, (клик)
kubednsDeployment := &apps.Deployment{}
kuberuntime.DecodeInto(clientsetscheme.Codecs.UniversalDecoder(), deploymentBytes, kubednsDeployment)
А еще есть сценарии, где тип, в который надо десериализовать, известен только в рантайме.
Главная сложность — реализация собственно десериализации и поддержка каталога типов, которые в принципе позволяется десериализовывать — никуда не делась (она внутри DecodeInto)
Главная сложность — реализация собственно десериализации и поддержка каталога типов, которые в принципе позволяется десериализовывать — никуда не делась (она внутри DecodeInto)
С генериками каталога никакого не нужно. В том смысле, что его за вас поддерживает сам рантйм языка, без каких-либо затрат со стороны программиста.
Если вы на работе не кайфуете, пилите что-то круто и не учитесь, то тогда это плохая работа и тогда понятное дело меньше-лучше.
- в гугле такие зп что люди «шикуют» относительно
-
нафиг мне то повышение сдалось?
ну каждый живет как хочет. кто-то хочет уметь дом, машину. а кто-то последние деньги тратит на путешествия.
Если вы смотрели видео то он говорил, что перейдет на фулл-тайм когда нужно будет платить ипотеку или учебы детям.
он «шикует» потому что в Гугле работал. Работал бы на обычную фирму, так бы не «выпендривался» рост зарплаты перестает приносить мотивацию
Деньги покрывают все потребности и смысла их больше зарабатывать нет
у каждого свои потребности. кому-то с любимым/ой и рай в шалаше
Если он для вас пример для подржания, то ради бога. По мне так звучит как мечта бездельника, без обид
Потом и этого стало мало, ведь JS сложен для восприятия и M$ сделала шикарный язык TypeScript. Этот язык в глазах многих разработчиков шикарная дама в корсете, но в моих глазах это безумный шляпник в смирительной рубашке. Ни каких больше фокусов и магии.
Самое же печальное в этой ситуации, что под давлением откровенно слабых разработчиков и их потребностей из мира разработки программного обеспечения вытесняются по настоящему эффективное использование ресурсов, повсюду программы, которые жрут как не в себя. Это про чудо софт написанный на базе электрона, и жирнющие сайты, которые раздувают браузер до мемов про оперативку и хром.
И ладно бы это давало ускорение разработки. Так нет же. Пишут тонны бойлерплейта, переизобретают одни и те же велосипеды на новом стеке. Меняют дизайн, ещё не закончив менять предыдущий. В результате и разработка медленная, и получающиеся приложения.
под давлением откровенно слабых разработчиков и их потребностей
вытесняются по настоящему эффективное использование ресурсов
Всегда было интересно, почему эти две истории должны противопоставляться? Что мешает сделать эффективное использование ресурсов для откровенно слабых разработчиков?
И возникает резонный вопрос — так ты за творчество или за бабки? Если за творчество — пожалуйста, есть множество open-source проектов, где пригодится творческий порыв. Если за бабки — делай, за что платят и не выступай. Множество же айтишников хотят усидеть на двух стульях: чтобы они, понимаешь, творили, а им за их творчество, соответственно, платили. Это еще можно понять в детском саду, но когда такое на полном серьезе излагают люди 30+, то возникают резонные сомнения в адекватности человека.
Позволить себе творчество могут только свободные (от проблем удовлетворения бытовых потребностей) люди, коих всегда считанное меньшинство.
Остальные, может, и стремятся к тому, да весьма ограничены в свободе выбора.
Высокооплачеваемый раб(отник) — всё еще раб(отник), потому что жить и творить в свое удовольствие по объективным причинам не может.
Строго говоря, в корне сидит причина не совсем объективная, а точнее «совсем не» — это экзистенциальная неудовлетворенность вследствие несоответствия потребностей возможностям, мелких психотравм, незакрытого гештальта и общей недозрелости личности (привет, инфантилизм из из первого абзаца).
— бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
— бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова
Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.
А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.
медицина, погода, ракетостроение, астрономия, прикладная физика/химия
Без знаний в предметной области чистый программист там будет работать в лучшем случае в статусе code monkey: «закодь-ка мне эту формулу, чтобы строился вот такой график вот этим цветом».
Мы моделируем реальность в мире машин, а я точно знаю: реальность — это не простая штука, в ней нет правильных и неправильных ответов. И у меня есть ощущение, что технологии вроде Go — это поиск простых ответов.
Я примерно так отвечал когда люди говорили что хаскел сложный — сложность инструмента должна соответствовать сложности задач, как у Стаффорда Бира — сложность системы управления должна соответствовать сложности объекта управления.
Был один «простой» язык — PHP, да вот оказалось что он годиться только для простых задач, а когда его начали применять в чуть более сложных, он превратился в джаву и потерял смысл.
Если ты уже умеешь гит, разве станешь юзать cvs в том проекте где его достаточно?
Это как писать телеграм ботов на go — то, что делается за неделю, программист на питоне делает за день, просто в силу того, что питон выразительнее. А производительность тут не особо играет роль.
Понятно, что любые категории это упрощение, но мне сейчас видится так. Хотя, если условный хаскел попадёт в образование и станет мэйнстримом, а значит привычным для большиснтва разработчиков, то может оказаться, что ниша условного питона очень мала.
То есть вплоть до того, что когда вам нужно написать какую-то консольную тулзу, вы просто пишите питоновскую функцию, добавляете библиотеку и она сама автоматически превращается в консольную команду.
По поводу творчества
В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов. Ничего не поменяется. Лично я не считаю, что это плохо. Конечно, растёт доля некачественных продуктов, но и количество хорошего ПО увеличивается. Можно сравнить эту ситуацию с элитарной и массовой культурой, плюсы и минусы есть и там, и там. Каждый решает сам, что ему ближе.
По поводу "элитарного клуба" программистов
И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока
Ваша цель – это сложность ради сложности. Чем сложнее процесс написания и чтения кода – тем лучше. Единственный смысл такого занятия – тешить своё самолюбие.
Также сразу встаёт вопрос, на что вы будете, например, жить, ведь ничего полезного для обычных людей вы делать не собираетесь. А значит и денег это занятие приносить не будет. На одном же энтузиазме далеко не уедешь.
Представим себе своего рода Шаолинь: монастырь программистов — монахов. Живут на подаяния, оттачивая искусство программирования.
Ездят с лекциями. Дают платные уроки программирования.
И даже можно придумать им сверхзадачу.
Например они — последняя надежда человечества перед лицом опасности прявления злобного ИИ.
Они должны суметь с ним совладать во время великой битвы интеллектов :)
В вашем тексте программирование можно легко заменить на написание книг или съёмку фильмов
Только вот книги или фильмы почти всегда — самоцель, конечный продукт. А код является самоцелью только в книжках Кнута. Но в иных случаях он всегда вторичен по отношению к задаче. Никому он неинтересен в отрыве от неё. То есть логически не получается (по крайней мере в том же ракурсе)
Каждый решает сам, что ему ближе.То есть если в кино абстрактная красота может иметь ценность без обоснования, то в коде только в контексте решаемой задачи (как это лучше поможет её решить).
Часто девиз бизнеса — безобразно, но единообразно. Но основное противоречие в том, что автор пытается реализовать себя в «работе на дядю». Дядя лучше знает, что ему нужно. И готов подавлять позывы рабочих к самореализации требованиями и деньгами. Дядя реализовывает себя.
Но кое-что может остаться кроме денег. Это квалификация, которую могут оценить другие и которая может открыть новые возможности. Если же и этого не остается, то из такого места надо точно бежать, если там не платят 100тысячмиллионов, использую которые можно себя реализовать или потом или в свои проектах.
Пришел к подобным выводам 7 лет назад и ушел в сисадмины. Сисадмин может себе позволить программировать для себя.
Так что теперь программирование это или скрипты для работы или хобби. Вот сейчас решил джаву вспомнить.
PS Ну, ладно. И за большими деньгами ушел. Тоже. ;-)
От созидания в эксплуатацию?)
И где это у админов большие деньги? В среднем меньше чем у кодеров
В том то и дело. Текущее программирование уже как бы и не созидание.
Как бы кратко сформулировать то.
Есть правила как назвать переменные, как назвать функции. Как построить работу модуля\программы\чего угодно. Есть правила для внешних интерфейсов для внутренних. Правила для всего. Делать какое то изящно-красивое решение — нельзя. Мало того что оно как правило больше времени займет, так и не поймет потом никто. Поэтому только самое простое, только в лоб.
Если вы пишете проект командой, то код который вы должны написать, он как бы уже виртуально написан. Просто вы его должны напечатать.
И самое ужасное — я отлично понимаю, что так и должно быть. Что все эти правила обеспечивают и понимание другими людьми моего кода, и мое понимание чужого, и я через год благодаря этим правилам пойму что сам же написал. И меньше ошибок будет и прочее прочее.
Кратко не получилось.
Тяжело не согласиться. Но это так только в прикладном программировании, а оно не одно в индустрии.
Про "виртуально" написанный код. Ну так виртуально много чего существует, просто мы еще этого не знаем. Почему и корректен именно термин "открытие" в науке. Все примеры решены, гипотезы доказаны. Это весь мир так устроен
Это вам не роман, какой к чёрту авторский стиль?!
Именно. Программист — инженер, а не писатель, вы реализуете спецификацию. Ваш код должен быть безликим, чтобы человек, который будет работать с вами просто вносил необходимые изменения, не тратя время на осознание вашего 'авторского стиля'.
Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар. Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже».
Напомню, что код пишется для людей. Если кроме вас его никто не может понять, то бизнес зависит от того, как успешно вы уворачиваетесь от автобусов. Завтра вы написали заявление по собственному — код можно выкидывать.
Впрочем, вы сами написали это ниже:
возьмут на моё место какого-нибудь дурачка, он легко сможет работать с моим кодом. Так компании будет намного комфортнее
Не можете написать просто и эффективно — страдайте.
Они не добавили дженерики в Go, потому что дженерики — сложные.
- В Go 2 дженерики будут
- Те, кто хотел, использовали кодогенраторы.
- Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода.
- C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
Я лично за единую архитектуру проектов в рамках конкретного бизнес-решения (мне нравится 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();
Т.е имея информацию о типе для дженерика создавать инстансы объектов. Всё это можно сделать в питоне, но придётся в явном виде передавать типы и интерпретатор даже не ругнётся, если где-то типы окажутся несовместимы / код упадёт где-то дальше.
Ну, исключая тот факт, что в питоне вам не нужно передавать тип, вы можете просто достать тип из объекта.
Вообще-то можно. Типы полностью никуда не исчезают, они всегда в рантайме были, хотя не везде, да и достать их не всегда просто. Гуглите например guava typetoken.
C# и Java обзавелись дженериками тоже не с первой версии, причём в яве на уровне рантайма они до сих пор не существуют — тоже как-то писали.
С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?
Проблема (была?) с дженериками в Go в том, что дизайнеры говорят, что это зло, а не то, что: «ребята, блин, неуспели, скоро допилим, ждите»
Это никак не мешает куче динамических языков — никто не жалуется на отсутствие дженериков в, например, питоне, на котором написано чуть более девяти тысяч сложного кода
Карл, зачем в динамических языках дженерики?
С каких пор это повод для подражания? Ну а в Rust'e они с первой версии и что теперь?
Я не говорю, что это повод для подражания. Я утверждаю, что отсутствие дженериков(и любых других фич языка) только усложняет работу, заставляя писать больше кода, но точно не стирает границу между сильными разработчиками и слабыми, как утверждает автор.
Простота — это красота.
Это абсолютно верно. Проблема начинается, когда упрощение работает против выразительности и безопасности. К тому же язык программирования чем-то схож с языком естественным, на нем тоже человек выражает какие-то свои мысли. И если тебе всё время нужно говорить про «снег», то хотя бы одно слово для этого нужно вместо «то, что холодное, белое и падает с неба». Это я к тому, что упрощение хорошо только до некоторого предела, гоу на мой взгляд эту грань перешел.
GitHub / open source, или это не то?
Во-первых неправильные вводные:
в гигантскую индустрию, где работают сотни миллионов людей.
Возможно автор забыл что на земле всего 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. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.А можно примеры? Ну кроме стандартной проблемы вызова асинхронного кода из синхронного. А то как-то ни разу в моей практике реальных проблем не было.
А так все верно, и про творчество, и про безликость.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.
Мне кажется, то что вы предлагаете, хорошо находит свое отражение в OpenSource. В котором бизнес не ставит ограничения по срокам. В тоже время, в OpenSource, для того, что бы оставаться конкурентоспособным стремятся решить проблему, в первую очередь качественно а не быстро.
в первую очередь качественно а не быстро.
Большое заблуждение и обобщение. Возьмем gitlab. Во многом образец open source продукта, только вот его приоритеты это набивание продукта фичами, а не исправление проблем. И исправлению ситуации не способствует даже то, что у них полно клиентов, которые им платят деньги и жалуются на проблемы постоянно.
Напротив, ненавистный golang именно по такой модели и разрабатывается. Очень осторожная разработка с предельным вниманием к качеству кода и большими сроками стабилизации продукта до того, как будет выпущена новая версия. 3 месяца разработки, 3 месяца тестирования и исправления проблем, релиз. Только вот автор там тоже будет не кстати. Там никому не нужно творчество и фантазия ради творчества и фантазии. Нужны простые и эффективные решения. А сложное, даже если оно быстро и полезно, порой и не примут. Такое уже было неоднократно. Недавно вон хотели более хитрый алгоритм сортировки добавить, но большая сложность кода стала препятствием. Не оправдывал прирост в скорости такую сложность.
Особенно проблемы с недоделкой фич. Многие вещи бросают на пол пути и в итоге оказывается, что, например, новый замечательный репозиторий контейнеров не чистит за собой и забивает людям диски терабайтами мусора. В планах было это сделать к 11.6, которая вышла на днях. План сорвался, т.к. и так туча фич запланировали. Сдвинули к 11.7. А появилась эта фича в 8.8, полтора года назад. Когда они это реально исправят черт его знает, а ведь это очень большая проблема.
Заниматься творчеством делая очередную систему учёта невозможно, если только вы не придумали новый подход к учету. Придумать его тяжело, потому что миллион людей уже об этом думали. А раз так, то делая учетную систему вы выполняете функции ремесленника, а не творца. Язык программирования тут ни при чем, просто посмотрите на другие задачи.
Проблема с «другими» задачами в том, что прочитав книгу “Go за 21 день» их не решить. Надо много знать за пределами программирования. Например, знать какой-то бизнес, или разбираться в математике и решать с помощью своих знаний задачи. Знание Go и очередного мега фреймворка никаких задач не решает и если это все, что вы знаете, то бизнес поставит вас решать типовые задачи, не требующие творчества и спец. знаний.
Начиная с сорри мини-выпиндрежа про «следите за пальцами», ханжеских рассуждений про порнуху через впн и пиратство, заканчивая «Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации» — wtf, это не идеализм, это банальное не понимание реальности. В реальности ты волен выбирать работать тебе на бизнес за деньги, или сосать лапу в опенсорсе, или комбинировать так, чтобы максимально удоволетворять свои потребности. Да даже не понятно что тут обсуждать и как это толком связано с названием «Безликий код убьет программирование, и ничего мы с этим не сделаем».
ЗЫ Кто-то должен был это написать — заметка ни о чем.
Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.
В хроматическом звукорядке, который используется в современной музыке, рассматривают 9 октав, каждая из которых состоит из 12 нот.
Семь нот — это лишь способ записи музыкального произведения, к которому добавляются знаки альтерации и ключи у нотного стана.
Пусть клмпании, желающие «урвать кусок прямо сейчас» его получат, и с ним в зубах сдохнут. Не мешайте им убивать себя.
А сами пока пилите свои проекты по всем правилам.
Проект жив только в руках Мастера.
В руках «эффективного менеджера» он умирает.
90% компаний закрывается в течение первого года, 3% продолжает существовать более 3 лет.
Философия языка такова, что на 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 килобайт, а код в этот лимит не лезет, то код вылизывать ПРИДЁТСЯ.
втиснуть 3D-алгоритм в ПЗУ боеголовки
пишутся на других языках
Намекаете, что сборщик мусора в боеголовке совсем ни к чему?
Несомненно, скоро какие-то задачи будут автоматизироваться простым наговариванием электронному ассистенту, но до упрощения разработки прочти как до ИИ, пока что она только усложняется. Проще стало решать вчерашние задачи, это да, но с развитием возможностей растут и запросы.
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока. Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым. Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Как б-женька смолвил, чуть не расплакался. Всегда стараюсь искать работу с тех. стеком, отбрасывающим на входе как можно больше бездарей и вредителей (например такие, которые делают rm -rf tests/
, если у них перестали проходить какие-то тесты, когда их на недельку оставили одних в проекте, случай из личной жизни), тем временем вижу всё меньше хороших вакансий, и кругом всюду требуются сплоншняком PHP/JS/Python/Ruby/Go-говноклады. Тенденция давно задана, и средний уровень престижа профессии стремится пробить всё новое дно. Хорошее программирование не будет убито, оно и так уже почти мертво.
По поводу статьи в целом можно согласиться, к сожалению, давно пройден тот этап, когда ИТ действительно жило прогрессом, даже менталитет сферы был другим, сейчас же даже начинающих туда влечет больше денежная и бизнес-составляющая, к сожалению, а каков запрос, такое предложение… печально
то мы придем к самой кривой и не оптимизированной автоматизации, какую только можно представить.
Ничего гугл что-нибудь новое запилит для оптимизации неоптимизированной автоматизации, 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, начинался как проект одного человека, а сейчас его перспективы весьма не плохие.
Несколько тысяч лед назад спроектировать двухэтажный дом могли единицы. И им нужны были сотни а то и тысячи носильщиков камней. Потом появились «типовые архитекторы», которые должны были проектировать по типовым схемам и проектам, но мы всё ещё знаем имено «творцов» (например Растрелли). А типовые архитекторы видимо возмущались, что им не дают творить. Теперь таких типовых архитекторов вероятно можно заменить софтом — никому не нужно творчество в прокладке труб в туалетах. Однако остались как гении уровня Захи Хадид и Хундертвассера, так и просто местные архитекторы, в результате творчества которых в моём районе все дома немного необычные. Плюс тут в том, что милиарды человек имеют крышу над головой, при этом не переживают, что это нестандартное решение развалится от порыва ветра.
С одной стороны, многих кодеров как и архитекторов, прокладывающих трубы, можно будет заменить автоматизацией. С другой, всегда останутся те, кто будут очерчивать общие контуры домов или софта, а дома и софт буду становиться дешевле, доступнее, массовее. Нужно всего лишь продолжать развиваться.
Я вот пишу для себя на Ассемблере Масм в npp — никаких «умных компиляторов», «умных IDE» и прочего. Только творчество, эксперименты. На заказ, к сожалению, это будет слишком долго и никому не нужно. Но, для работы на заказ есть другие вещи, скажем, C++17 и Visual Studio.
Я бы всеми силами держал порог входа в программирование как можно выше, чтобы инструменты не подстраивались под усредненного разработчика, когда опытный инженер и вчерашний выпускник курсов вынуждены писать одинаковый код.
Есть подозрение, что порог входа и так слишком высокий. Только не потому, что кто-то так специально сделал. А потому что софт/инструменты/языки/конечные продукты — сырые. (Самое время вспомнить байку про Джона — серийного программиста). И виноваты в этом все ;) С одной стороны бизнес, который не даёт время сделать хорошо. С другой стороны программист, который занимается избыточным перфекционизмом там, где можно было бы сделать просто. Да и вообще, просто — это не всегда плохо. Часто это хорошо :)
Да грустно наверное автору. Думал вот плтрачу пол жизни буду изучать все и стану крутым программистом незаменимым супепстаром и покажу всем кто тут самый умный. А в итоге профессия поменялась так сильно что любой новоиспеченный мидл ничем не хуже тебя.
Кажется, что автор чем-то обижен на Go. Может его набирающей оборот популярности? А на самом деле Go абсолютно не отменяет никакие парадигмы программирования, практики и шаблоны. И на Go можно написать плохую программу.
Да появятся ремесленники от программирования, потом их заменят автогенераторами, но «художники» которые смогут реализовать идею «изящно» всегда будут.
Момент, когда у тебя забирают возможность выбирать, как этот код будет работать — мой самый страшный кошмар.
Хочу вас расстроить, но этот хоорор уже вокруг нас.
Сейчас вы можете писать очень много умных вещей, но компилятор потом все ваши умности конвертнет в векторные вычисления и прочие совершенно нечеловеческие паттерны. Нечеловеческие в том с смысле что такой код люди написать конечно могут, но потом прочитать и понято что этот код делает смогут не многие и не сразу.
Можно ещё провести аналогию с ДНК…
Необходимость в сложных алгоритмах и архитектурных решениях никакая стандартизация и безликость кода не убъет. К счастью или к сожалению, таких задач их меньше, а для обычного штамповочного кода подойдет и конвеер.
Так что если не нравится быть оператором конвеера, то стоит все-таки углублять свои фундаментальные знания и способности к самообучению и идти уже в системные программисты, а не прикладные.
Потому что готовый продукт важнее его реализации.
Да, да, тысячи раз ДА! Это же самый-самый кайф! Вот ты доделываешь фичу, выкатываешь в продакшен — и жизнь пользователя становится чуточку лучше. У него меньше головных болей, потому что сервис что-то автоматизировал, что-то теперь не нужно делать руками… Или он благодаря твоей работе может интересно провести время, получить удовольствие или расслабиться — привет компьютерные игры, браузеры и т.п. Разве это не офигенно само по себе, что относительно небольшими усилиями ты хотя бы чуточку меняешь жизнь других людей? О_о
Из похожего — съёмки развлекательных видео например. За этот год у меня на махоньком ютубовском канале (40 тысяч подписчиков) зрители насмотрели 2 миллиона просмотров. 22 миллиона минут. 40 человеко-лет. Хотя я со своей стороны затратил за год на эти видео суммарно даже не человеко-месяца. Это же… обалдеть какое соотношение усилий/результата, если попытаться в голове удержать!
Ну и блин, как можно не находить творческих задач даже в «текучке»? Да любая, даже самая шаблонная задача всегда содержит простор для размышлений! Как поменять наименьшее число слоёв, чтобы передать данные отсюда сюда? Как оптимальней распределить работу между клиентов и сервером? Или вот мы делаем в месяц 2-3 рутинные задачи такого типа — как бы это автоматизировать, чтобы рутины вот конкретно здесь стало меньше? И такие задачи на каждом, блин, шагу!
Я бы посоветовал автору почитать вот это: The 10 rules of a Zen programmer, особенно обратить внимание на часть 4.
Так что работа будет, может просто не совсем в такой форме
Хочется тебе нечто большего?
Есть ощущение, что ты делаешь ТУПОЕ ГОВНО, ДЛЯ ТУПОГО ГОВНА?
— Ну так развивайся!
Меняй специализацию, изучай новые фишки, куча интересной фигни в этом вашем IT: II, Machine Learning, VR, BlockChain.
Вперёд! Пиши свои мудрёные и изящные алгоритмы, задавай стандарты! А не ворчи, как старый дед, про то какие все вокруг бездари.
Нужно обычное. Потому что готовый продукт важнее его реализации.
Таки да!
Вот к примеру, беру сейчас мобилу в руки и если честно, то я понятия не имею как много раз разработчики прошивки и программ писали goto? Меня лишь заботит исключительно функциональность и производительность относительно моего субьективного представления. К примеру, если я считаю, что смс-ка должна отправиться за 1 сек., а отправляется за 7-10 сек., то мне абсолютно до лампочки как много хороших практик применил разработчик в коде отправки смс-ки! И так думает почти 95% пользователей ПО.
Далее. Чисто из экономических соображений. N руб. сегодня не равно N руб. завтра! Есть инфляция. Если вы провозитесь с решением на K дней больше находясь в поисках хорошего варианта, хотя можно было написать пусть не идеальное, но рабочее и качественное решение и за это время продукт из-за инфляции упал на 1 руб., то в случае с 1.000.000 пользователей это 1.000.000 руб. А за эти деньги можно много чего для бизнеса решить, к примеру выдать вам зарплату!
Позиция «Мне платят за выбор из разного вариантов лучшее» — ошибочна! Вам платят за решение рабочих задач на уровне «Необходимо и достаточно».
Вы, как разработчик, абсолютно ничем не рискуете. Легко можете поднять мягкое место и найти другого работодателя, который будет вам выдавать новые задачи. А вот работодатель рискует! Продолбанные сроки перед заказчиками — факап. Неуспели поставить пользователям билд, а уже новый год встречают и они не работают и как вывод не покупают софт — факап. И много много других факапов может быть из-за «Я искал лучшее решение». А потом к работодателю приходит Вася и говорит «Я вот тут работал и искал лучшее решение. Месяц прошел. Выдавайте зарплату» и ему как правило насрать, а сумел ли работодатель продать софт или нет
Тут есть очевидный конфликт интересов.
Бизнес заинтересован, чтобы разработчик день ото дня методично выкатывал нужные фичи с приемлемым качеством, т.е. выполнял тупую рутинную, невероятно скучную работу.
Разработчика волнует свой карьерный рост и чтобы работа была хотя бы иногда интересной. Если он не будет изучать новые технологии, то завтра его выкинут с той же работы и наймут, новых которые знают современные языки, фреймворки, платформы. Он пробует всякие новые языки, фреймворки, технологии, подходы и архитектурные решения, которые очень часто бывают плохим решением данной задачи, но хорошии для будущих проектов и карьеры.
Есть люди ничем не интересующиеся, к примеру от них можно услышать: «а зачем мне марофон пробегать?» или «А зачем мне в хакатоне учавствовать?» или «А зачем мне на лыжи идти?» или «А зачем мне куда-то ехать пострелять?» или <подставьте, что придет в голову>. Им в принципе вообще не интересно! Уперлись только в одно занятие и сидят в нем.
А есть другие! Они и IronMan-ы проходят. И марафоны бегут. Еще и для мобилы аппликуху запилят и еще 100500 всего. Им все интересно! Как правило у них другой вопрос «Где на все взять время?» ведь все так интересно.
По поводу способностей и навыков: все развивается!
До августа 2016-го я умел плыть только одним стилем «топор ко дну», а в июле текущего 2018-го переплыл Босфор. В прошлом году понятия не имел что такое Promise, а сейчас не только его, но и async\await пишу и не особо боюсь и много чего другого тоже применяю.
было бы желание!
Но сейчас читая про Босфор, я понимаю, что надо бы мне с него начать… Гибралтар сильно круче.
P.S. Несмотря на все эти минусы мне нравится мой стиль жизни, но при этом я прекрасно понимаю что такое распыление скорее всего отсечет меня от интересных мест работы. Я не попаду в те самые 0.1% программистов которые чем то интересным занимаются. Точнее не совсем так, мне было в какой то мере интересно и то чем я занимался раньше, и то чем буду заниматься теперь, но это не настолько интересные занятия чтобы отдать им вообще все свое время.
В итоге что? Правильно, из меня и программист так себе, и велосипедист, и языки эти я знаю через пень колоду
Почему посредственный?
Вы не задумывались о том, что может быть вам еще каких-то навыков не хватает? Что к примеру у вас с английским? А умеете ли вы продавать идеи? К примеру убедить коллег использовать ту или иную технологию это тоже «продажи».
Огромное кол-во людей стукнувшись о трудность думают, что он сделал все что мог. Буквально недавно у меня был затык в webpack-конфиге. Я реально думал, что меня уже гугл матом посылает. Оказалось, что нет, что можно по-гуглить чуть чуть по-другому и проблема решается.
Это про то, что сделанные нами выводы не факт что истина.
Почему посредственный?
Ну как, алгоритмы и структуры данных знаю очень плохо, ОС писать не умею, математику знаю на уровне школы, и еще много похожих пунктов. У меня Скиена до сих пор не прочитанный, как и «Дискретная математика для программистов», как и таненбаум, как и банда 4-х, как и многие другие нужные книги из за того что времени много на другие интересы уходит.
Второй вывод: наиболее удовлетворенным я бываю, когда вижу, что у меня есть выбор, на каком ЯП я могу решить ту или иную задачу (ессно когда нет ограничений в стеке). Т.е. нет плохих языков, просто есть задачи которые для них не подходят.
И да, забыл внести свою лепту в обсуждение: GO интересный язык. Прикольный :) Его ограничения и заставляют как раз заниматься тем самым творчеством :) И иногда, сделав рефакторинг архитектуры, чтобы убрать свои фантастически красивые костыли, понимаешь в чем был смысл этих ограничений. Да собственно говоря это наверное к любому ЯП относится.
ТС, если хочешь и денег и творчества — иди в ресёрч отдел какой-нибудь большой компании. Там тебе и денег много дадут и твори сколько влезет интересные вещи.
Вот тебе совет. Найди контакт (вот тебе твиттер @lorentzframe) Браяна Бэкмана (он очень дружелюбный и открытой человек) из бывшего Microsoft Research и текущего Amazon Robotics; спроси у него как попасть в этот самый Microsoft Research; набери скиллов которых ещё нет и стучись к ним. Дерзай, в общем!
Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.
С тем же успехом можно сказать, что сегодня любой вчерашний лох-продавала из салона сотовой связи, выбившись в топы, будет указывать всем, как жить.
Что сказать? Ищи место, где боссы адекватны, готовы платить за творчество, и влияй на развитие этого места. Открой курсы программирования, в конце концов, и — твори!
Мои мозги обслуживают мелкие ежеминутные хотелки, чтобы люди принесли мне деньги, чтобы я тоже удовлетворил свои хотелки.
Краткое и точное описание любой работы. Мы берём чужую лень, свой мозг (рыбное филе, например, порубить — тоже мозг нужен) и трудимся на неё и за это получаем возможность воплотить свои хотелки и быть ленивыми вне своих областей.
И тем более это справедливо для бизнеса. Бизнес ориентирован на людей и их нужды здесь и сейчас. И это нормально.
Если же Вам хочется и вклад в человечество сделать, и творчеством при этом заниматься, и иметь гарантированный кусок хлеба без давления временных сроков и прочих бизнес-радостей, то надо идти в науку. В разработку действительно сложных, долгосрочных систем для будущего, в разработке которых нужен весь мозг и ещё столько же. Но там, за возможность спокойно жить и творить, отнимают хотелки: финансировние бюджетное, от спонсоров проекта — в лучшем случае. Ну, Вы всё это и так знаете, в общем-то.
или наоборот))
бизнес плох только тем, что использует любой кусок гуано, если он дешевле других решений. так мы пришли к докерам и оргиям в ansible. и жирнолисам.
А то, что происходит автоматический контроль стандарта оформления кода — так это прекрасно! Если есть автоматический контроль, значит где-то рядом есть (или будет) автоматический «бьютифаер». Не нравится имеющийся стиль — переформатировал, так как тебе удобно, поработал, накатил старый «корпоративный» стиль, отправил в Git. В чём проблема?
В Питоне, например, нет скобок и нужно, блин, использовать отступы — это что, ужас-ужас? Да, нас лишили стиля «кирпич кода», однако никто от этого не умер.
![image](https://habrastorage.org/getpro/habr/comment_images/9bc/d90/0a5/9bcd900a50991afeb51b5d0a7fc42373.png)
иллюстрация из статьи 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 отлично проходят на всех трех БД (пруф). И да, на работе я использую это чудо в каких-то не сильно важных сервисах :)
Раньше программирование было делом избранных, сейчас любой лох посидит на курсах годик и пойдет писать код.Раньше? — Это когда?
В середине 70-х прошлого века — когда писали на ЯМБ (язык машин бухгалтерских) печатая программы на телетайпе ЭВМ «Наири-2»?
В конце 70-х прошлого века — когда вызывали «Джина» на БЕСМ-6 чтобы скормить ему программу на Фортране?
В середине 80-х прошлого века — когда запускали колоду перфокарт на PL-1 через устройство ввода перфокарт «EС-ЭВМ»?
В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
В начале 90-х прошлого века — когда переписали всё что было на Foxpro и Clipper?
В середине 90-х прошлого века — когда таскали «мышой на форму» в Дельфи?
В конце 90-х прошлого века — когда «писали классами» Java, от радости как кипятком?
В середине 00-х — когда вовсю использовали Mysql?
В середине 10-х — когда освоили jQuery и страницы веба ожили?
Или в настоящее время — когда все перешли на JavaScript, шуганув оставшихся по нишам?
Год, назовите fillpackart год? (С)
Я до сих пор испытываю трепет и уважение перед людьми кто могут писать на ассемблере.
Наверное есть в этом все-таки часть правды. Но с другой стороны скорость разработки несопоставима. То что можно написать на JavaScript за день и то что можно написать на ASM за день — это же как современный телевизор сравнивать с наскальными рисунками, с точки зрения функциональности и пользователя. Для каждого языка и инструманта есть свои задачи.
А те времена характеризовались тем, что программист был один на один с ЭВМ. Пустой. Не только среды разработки или компилятора, нет ни одной команды, кроме тех, что напишешь сам. Отсюда и ощущение, что скорость программирования на ассемблере отличается на порядки.
Современное программирование состоит в основном из обращений к библиотекам.
Да библиотеки очень важны. Но разработка на острие ножа — она как раз менне всего завязана на библиотеки. И самое интересное создается скажем так «создателями библиотек».
Попробуйте посмотреть количество инструкций CALL в коде, который пишете «без использования библиотек». Проблема работы на ассемблере была в том, что прежде чем написать CALL, нужно было самому создать процедуру. Поэтому получалось так медленно. Когда речь пошла о создании ассемблерных вставок в код на Паскале ради выигрыша в скорости, трудозатраты оказались совсем не так велики.
Это «убило творчество», но резко повысило надежность программ.
В конце 80-х прошлого века — когда писали на Natural в СУБД «Адабас» с превосходством поглядывая на тех кто писал на Коболе?
Adabas это 70-е а Natural начало 80-х. Мы как раз недавно завершили проект по миграции софта, который работал с начала 80-х на мейнфрейме. Пришлось покопаться в коде на Natural для Adabas. В те времена это было круто, сейчас смотрится ужасно.
Интересен сдвиг восприятия — с одной стороны, в то время софт был написан быстрее и много меньшим количеством людей, чем мы потратили сейчас. С другой — просто реплицировать то, что было сделано тогда, сейчас таки можно сделать гораздо быстрее.
Раньше? — Это когда?
А ответ простой, и он не в языках и технологиях, а в доступности.
Раньше — это когда надо было выбивать себе в ВЦ «машинное время», и среднему обывателю недоступно было ничего, кроме калькулятора (непрограммируемого, само собой) за половину средней зарплаты.
А теперь — это когда вы работаете на инструменте, который есть у каждого. Поэтому и шарм с романтикой такой работы девальвирован чуть более, чем полностью. Только высокий спрос на поделки (ввиду огромного их количества) держит и соотношение порог_вхождения/выхлоп (доход) достаточно высоким, чтоб в кодерство шли все,
А ответ простой, и он не в языках и технологиях, а в доступности.Вряд ли 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 — проще было их все переписать, — чем разобраться в них и что-то поправить.
Свобода! Неосторожным движением можно переопределить константу.
Но ведь автор обсуждаемой статьи жалуется ровно на то же самое: написать программу на Go можно гораздо меньшим числом способов, чем на привычных ему языках. Безликий код. Никакой свободы. Убивают творчество. Нужно противостоять. Я сомневаюсь, что нужно. Слишком хорошо помню что бывает от излишней свободы.
хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности
Мне кажется вы немного путаете понятия сложности самой системы (которая с одной стороны как раз вредит надежности, так как чем больше механизмов в устройстве или кода в программе — тем потенциально больше проблем можем с этим возникнуть) и сложности при разработке и поддержке этой системы. Да, сейчас школьник может написать программу для смартфона по распознавания текста на фотографии, не умея даже собственного сервера и никакого опыта в машинном обучении, просто повторив туториал по какому-нибудь TensorFlow.
Сложнее всего ведь создавать простые вещи, которые будут работать и быть надежными, потому что они простые.
Go или Rust или другие языки связывают руки программисту, не давая выстрелить в ногу, в то время как на C/С++ вы вольны это сделать. Но попробуйте сейчас написать json-парсер или http-сервер на C. Вам точно пригодится высшее образование. На go это сделать проще и благодаря этому мы можем строить бóльшие и более сложные системы, которые будут кроме этого надёжны и просты в поддержке.
Кажется, будто из-за этого профессионала с годами стажа может заменить выпускник университета, но это не совсем так. У профессионала есть опыт, просто раньше это опыт, условно — искать глазами в коде возможные разыменования nil-ов (зачем эти ваши новомодные статические анализаторы, ими только новички пользуются, а я ведь профессионал!), а теперь это опыт другого характера — пусть даже написать на вечер сервис, на который раньше была нужна команда программистов и месяцы работы.
изучение было с С, потом С++, потом 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, но нет реляционной алгебры.
Что-то раскажут про ООП, но нет теории конечных автоматов.
Сотни часов на обучение конкретным инструментам. Но подсчитать алгоритмическую сложность не умеем.
Я уже не говорю о том, что ни про логическое, ни про функциональное программирование студентам вообще не упомянут.
«Позабудте индукцию и дедукцию — давайте продукцию».
Что же говорить о всевозможных курсах «программист за два месяца».
«Сначала изучение и анализ области, потом попытка формализации процессов в более менее читаемом виде вкупе с построением работающей системы из доступных составляющих.»
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистов. А чаще уже не приходит — удается обойтись подбором и настройкой готовой системы.
Вот типичная программа современного вузовского курса по специальности инженер-программистНе могу согласиться с вашим резюме по образованию инженера-программиста. У нас было многое базовое из того, что вы полагаете отсутствующим, и кое-что неупомянутое вами, и меньше инструментов (у вас аж 4 языка изучается, неужели такое где-то есть?). Могу согласиться с тем, что в работе требуется намного меньше, чем изучается, и с низким уровнем кадров в постсоветском образовании (некоторые предметы некому вести).
Разработка реляционных баз данных в MS SQL Server 2012. Язык запросов Transact-SQLОбычно курс разделен на несколько частей. Вот на примере, типичный предмет: на лекциях проходится в каком-нибудь виде реляционная алгебра, на практике какая-нибудь РСУБД.
UML. Технология программирования и моделирования программных системСамый близкий к стереотипичной инженерии курс, по-моему, и реже всего используемый в работе до уровня сеньора. Наверно, из-за незрелости индустрии программирования.
А это совсем другая профессия — аналитик. Иногда со знанием программирования, иногда без. Вот когда формализация закончена, приходит черед программистовЭто часть профессиональных обязанностей инженера-программиста. В очень крупных проектах выделяются аналитики, чья единственная работа — анализ бизнеса, но в своих поддоменах программистам приходится разбираться — аналитики не выдают алгоритмы, они тоже довольно обобщенно описывают среду. Единственное формальное описание процессов — это код. В некрупных проектах программисты зачастую — единственные аналитики, которые разговаривают с бизнесом.
Но когда я сейчас прихожу в организацию и провожу анализ, мне не приходит в голову писать что-то серьезное самому. Я говорю: вам подходит вот такая система, при правильной настройке она покроет все ваши задачи. Вряд ли описание бизнес-процессов в специализированной среде можно назвать программированием.
А промышленные системы пишут крупные команды с очень четким разделением функций. Кустарь-одиночка не может с ними тягаться.
Впрочем, одну такую команду я и сейчас знаю. Два доктора наук ведут разработку в своей области более тридцати лет. Программисты они так себе, но суть проблемы и математический аппарат понимают настолько глубоко, что развитие продукта идет удивительными темпами. Пользователи уверены, что работает команда человек в тридцать. но это все-же «уходящая натура». Реликт времен, когда каждый программист был ученым или по крайней мере инженером.
Это действительно рабочие: знать устройство своего «станка» не требуется, только органы управления; подбирать «режимы резания» не нужно — все есть в «технологической карте». И с точки зрения организации крупного производства это правильно.
Ну вот выделится какое-то количество некомерческих программистов. Что случится с коммерческими?
От самолетов и домов зависят жизни, в любых таких областях строгая регуляция. Но IT в основном состоит из менее критичных областей. На плохом самолете летать страшно, поэтому я буду платить много за гарантии, а пользоваться забагованным текстовым редактором — нет, за отсутствие багов я много не заплачу. Вполне свободный рынок.
1. Высококлассные спецы должны создавать тулзы для построения систем. Их нужно мало и они должны быть очень тщательно спроектированы.Любопытно. А в вашем идеальном мире только программисты должны быть высококлассными, или вообще все специалисты? Что остальным делать, кто не стал высококлассным?
2. А вот пользоваться этими тулзами должны специалисты в предметных областях в декларативном стиле.
Нужно понимать, что ИТ — это инфраструктура цивилизации. И основание её на бизнес интересах до добра не доведёт.В СССР IT было вспомогательным инструментом народного хозяйства, что по сути то же самое, что и интересы бизнеса. Что капиталистический, что социалистический директор будут подпинывать программиста закончить автоматизацию. А на чем базируется IT в вашем мире?
— вот по таким же критериям когда-то жрецы и попы сохраняли письменность и все знания о мире только для себя — не для быдла такие сокровенные и сложные знания! И таки им удалось затормозить развитие человечества на века. ))
Достаём Ленина из саркофага, покупаем броневик…
Короче строим коммунизм!
Ну и я не вижу в этом проблемы. Нормальные, творческие личности всегда востребованы обществом. Если бы их не было, то мы вряд ли бы выбрались из каменного века.
Нормальные, творческие личности всегда востребованы обществом.Это неверно.
Тут много вопросов:
— что такое «нормальные» — это какие? — больше зарабатывающие?
— что такое «творческие личности»? — которые творят что-то новое и неважно что это новое вредно, никому не нужно, никому сейчас не нужно, неизвестно нужно ли вообще, неизвестно нужно ли будет вообще и с какой целью (вредной, нейтральной или критической спасительной?)
— всегда востребованы обществом? — Полно примеров в истории, когда творческий личностей общество гнобило вплоть до сжигании на костре. — Вам наверняка надо изменить тогда ваше определение:
Нормальные, творческие личности всегда востребованы нормальным прогрессивно-мыслящим обществом.
Но тогда вы должны будете определить что есть «нормальное прогрессивно-мыслящее общество» и есть ли это «общество потребления» — то есть общество «капиталистическое»?
Если вы глубоко и рекурсивно помыслите — то вы придёте к необходимости какой-то аксиомы в виде Нормы или Традиции (то есть Веры, она же породит Религию, разговоры о которой гнобимы на Хабре).
Капитализм основан на старой аксиоме — Нельзя закапывать свой талант в землю ибо это грех. (С)
Все остальные рассуждения есть типа «теоремы», стоящие на этой аксиоме.
Однако, как только вы решите "проявить гордыню" и заявить во всеуслышание, что вы сами решаете что делать со своим талантом — закопать его или явить миру? — вы выбиваете эту аксиому из-под ног капитализма и «летите в пропасть» (или вы собираетесь эту аксиому чем-то заменить?)
А деньги? — чем мерить талант? — трудоднями? — почётными грамотами? — разрешением на выезд за границу? — процентом по кредиту? — путёвками в санаторий? — отрезом на костюм? — красными шароварами? — кармой? — лайками?
А нужно ли его мерить? — А как без меры явить его миру? — Ибо явление миру и есть… измерение! — Не так ли?
Что предлагает fillpackart? Он предлагает измерять путём создания нечто типа «закрытой академии программирования»:
Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации. И чтобы их приоритетом было глубокое совершенствование технологии, свободное от ежедневного потока.
Так поступали ранее (смотри первые Академии) и так поступили однажды… французы (смотри Пантеон куда они помещают ушедшие таланты свои) и так поступили математики (когда их труд отверг как полезный сам Нобель) введя свои премии и медаль.
Но когда уже есть всеобщий измеритель Таланта и это есть сам талант (то бишь деньги), то все эти измерители для сидящих в «высоких башнях из слоновой кости» похоже уже больше не нужны. Поди.
Из объяснения я понял, что он занял первое место, потому что каждая ее деталь штапуются одним ударом дешевого пресса из дешевого металла. В то время как для производства требуется ламбо, нужно очень сильно извращаться, и тогда ко мне пришло понимание, что творчество в простоте.
Знаете, сейчас еще в моде сейчас вручную рисовать фотореалистичные изображение, так вот это не творчество — это онанизм. Творчества и искусство — это двумя штрихами передать все эмоции, а не два месяца вырисовывать какую-то херь, которую можно одним нажатием кнопки сделать.
Втиснуть свой проект в примитивные простые паттерны, который каждый джун поймет, а не городить огород велосипедов на костылях, который можно понять только обладая 20 летним опытом в программировании — это и есть красивый код, а то что вы называете красивым кодом — это мастурбация.
Как большинство «проблем», эта — в голове, а не в мире. Проблема — это противоречие. В частности, идеализированные картинки (например, про «высокое программирование»), порожденные из наших личных предпочтений, против реальности.
Во-первых, нужно принять, что мир сейчас, в данный момент, устроен так, как он устроен. «То, что есть — есть. То, чего нет — нет.» Отрицание реальности служит плохую службу.
Во-вторых, нужно увидеть свое место в мире в данный момент, и сразу станет понятно, почему к нам предъявляют именно такие требования, какие предъявляют (можно будет перестать этому удивляться и ожидать чего-то другого). Страус не выживет в Антарктиде, а пингвин — не выживет в Сахаре. В коротком времени подсистемы определяются условиями надсистем.
После чего нужно самоопределиться: или я остаюсь здесь (и тогда бессмысленно на что-то жаловаться — просто будь тут и живи на 100%), или я проявлю активность по отношению к своей проблеме — например, иду в другое место, более соответствующее моим амбициям и ценностям (может, и найдешь), или я говорю, что возьму и изменю это место! Не так много вариантов: остаться (подварианты: продолжать ныть или полюбить то, что есть), уйти, изменить.
В последнем случае самое глупое — пытаться изменить сразу весь мир (это опять романтизм и идеализации), нужно найти маленькую-премаленькую область твоего окружения и попробовать изменить ее. Скорее всего это не получится (или получится, но не совсем то), но в процессе человек что-то понимает и еще меняется сам. А может, и получится, и тогда это заряжает на кратно большие усилия к изменениям.
Становясь многократно в активную позицию, меняя места обитания, и обламываясь о полу-успешные попытки изменения, принимая реальность, и где-то чуть-чуть меняя её (чаще всего все равно не так, как нам бы хотелось), мы растем и живем.
И со временем наши старые проблемы начинают видеться совсем с другой стороны, казаться смешными, трансформироваться в просто обстоятельства.
И это все вообще не о программировании.
Ну ты и чмошник, хейтерок) 🤣 уже вроде как год минусишь мои комменты? вот жешь ты лузер) так бомбануло, что уже год только обо мне и думаешь 😂 только ща заметил, лол
Безликий код убьет программирование, и ничего мы с этим не сделаем