Дисклеймеры
Кому-то данная статья покажется стёбом. Если вдруг вы обнаружили себя в этой категории, попробуйте вспомнить старый афоризм "В каждой шутке есть доля шутки". Может быть, это поможет вычленить ту самую долю.
Было бы интересно подискутировать с кем-то по сути, а от споров по частностям (в том числе описанным в статье) буду дистанцироваться.
В общем, я предупредил, а уж вам решать, что с этим делать. Приступим...
Поветрия
Я наблюдаю за развитием IT в течение приблизительно четверти века, и с каждым днём меня всё сильнее удручает происходящее.
Постоянно мы слышим, что какой-нибудь паттерн или язык становится всё более модным, а что-то, напротив, — уходит в историю. А ещё различные поветрия о "хорошо или плохо" будто волнами перекатываются через это вот всё.
Кто-нибудь скажет, что это — естественный ход событий — просто одна технология заменяет другую. И он будет прав и неправ одновременно.
Увы, новые вещи (коих не так чтобы вообще есть16) всё чаще приносят с собой и очевидно деструктивные, будто навязываемые извне, паттерны.
В прошлом частота таких деструкций была невысокой, но выглядит так, что она нарастает по экспоненциальной кривой.
В этой статье я хотел бы поговорить о причинах происходящего.
Однако, чтобы обсуждать предпосылки, нужно сперва сформулировать или описать само явление. Поэтому начнём со сравнительно далёкого прошлого.
В общем, как-то раз один с виду вроде бы неглупый человек ляпнул в публичном пространстве совершенно необоснованное суждение "о вредности оператора goto"1.
Начавшаяся после этого вакханалия растянулась более чем на полвека, а количество ущерба, нанесённого этим поветрием, настолько велико, что приходится дистанцироваться, чтобы его обозреть.
Миллионы адептов — отрицателей goto до сих пор наводят ужас на окружающих. Десятки новых языков программирования остались инвалидами, поскольку ещё на стадии дизайна не включили этот оператор в свой набор.
В итоге в обществе сложился устойчивый стереотип:
—
goto— зло!— Почему?
— Ведёт к запутанному коду!
— А ведь есть случаи, когда, напротив, — полезно, что с ними?
— Даже если и так, всё равно,
goto— ужасный оператор, ему не место среди порядочных людей!
Именно Дейкстра был основателем первой крупной секты хейтеров нормальной, в общем-то, технологии. В результате миллионы людей осудили инструмент только потому, что какой-то "авторитет" что-то там сказал. И им плевать на то, что такие вещи, как высокоскоростные однопроходные парсеры или, например, код, выполняющий зависимую инициализацию и деинициализацию нескольких ресурсов, пишутся с goto так, что по-другому лаконичнее и эффективнее не сделать!
Событие, принёсшее нам практически всенародную ненависть, направленную на goto, — пожалуй, самое яркое и длительное по времени, но, увы, не единственное.
Поветрия, моды, снова поветрия... Следуя одно за другим со всё более увеличивающейся частотой, они приводят к тому, что многие хорошие и полезные вещи оказываются либо утрачены, либо заклеймены, либо (что самое поганое!) замещены их отрицанием.
Помимо уже довольно устойчиво вбитого в головы штампа "goto — это плохо", мы окружены множеством других, не менее деструктивных.
Взять, например, современное "Статическая типизация — хорошо, динамическая — плохо". И эта чушь началась прямо в тот момент, когда, казалось, были все шансы, чтобы языки программирования встали в один ряд с человеческими! Мда...
А ещё в наше пространство вторглись линтеры, не только верифицирующие код на предмет возможных ошибок (что в целом хорошо), но и указывающие нам, "сколько пустых строк ставить между блоками", или "в каком порядке импортировать модули15!"
Кстати, поветрие о преимуществах статической типизации, как мне кажется, растёт оттого, что для неё проще писать линтеры. Других разумных объяснений нет.
Впрочем, каталогизация поветрий и мод — тема отдельной статьи (и я планирую её как-нибудь написать), а здесь я больше хотел поговорить об очередной современной напасти — о микросервисах.
Но прежде чем мы до них доберёмся, ещё немного лирически отступим и добавим в контекст рассмотрения некоторое количество вопросов иного плана.
Фрагментация мышления
Помимо поветрий, всё больше бросается в глаза усиливающаяся фрагментарность мышления среднестатистического программиста.
Причём, мне кажется, что причины этого явления и обсуждаемых выше поветрий одни и те же.
Фрагментарность мышления выражается в склонности программиста зацикливаться на частностях или мелочах, не глядя на картину в целом.
(Вообще проблема касается не только программистов, но, поскольку мы говорим о мире IT, ограничимся пока этим подмножеством)
— А этот тикет вы зачем (сами себе) написали?
— Это же технический долг!
— Почему вы считаете это долгом?
— Если доделать так, как здесь написано, то функция вместо 6 миллисекунд будет выполняться 600 микросекунд. Круто же?
— Нет.
— Почему?
— Потому что эта функция запускается один раз в сутки. Даже если время её исполнения будет равно 600 секундам, то это всё равно будет устраивать абсолютно всех пользователей.
Общаясь с десятками и сотнями программистов, я отчётливо вижу корреляцию: именно люди с фрагментарным мышлением наиболее склонны поддерживать поветрия (и наоборот).
Рассмотрим ещё пример. Движение к лучшей утилизации имеющихся ресурсов привело IT к широкому использованию асинхронных парадигм программирования, а они, в свою очередь, не могли не дать новых языков программирования.
И вот, крупная международная корпорация, для разработки нового инструмента привлекает одного некогда умного, но ныне довольно старенького, ставшего маразматиком, специалиста. И всё бы ничего, но только он толкнул в массы новую "мегаидею" (по аналогии с "goto — это плохо"): "Исключения — это плохо!"4.
И теперь тысячи — нет, уже миллионы — программистов в каждой первой функции пишут повторяющийся код, засоряющий пространство на экране:
func foo(a, b string) (int, error) {
// весь мусор про `err` мог бы быть реализован компилятором
res, err := bar(a, b)
if err != nil {
return 0, err
}
return res + 1, nil
}
func bar(a, b string) (int, error) {
// весь мусор про `err` мог бы быть реализован компилятором
res, err := baz(a, b)
if err != nil {
return 0, err
}
return len(a) + len(b), nil
}
Если вернуться к фрагментарности мышления, то крайне характерно, что один и тот же разработчик будет, с одной стороны, с пеной у рта утверждать, что исключения — это плохо и в Go всё сделано правильно, а с другой — не будет видеть целого за частностями (прикладывая массу усилий к улучшению фрагмента, не думая об общем).
Как докопаться нам до истинной причины? ©
Внедрённая в коллективные мозги глупость "исключения — это плохо" привела к тому, что уже минимум два весьма популярных языка построены на этом базисе.
Скольким людям теперь не удастся "за деревьями увидеть леса"? Страшно помыслить!
Может показаться, что все эти поветрия придумывает какой-то злобный гений, однако, несмотря на то что у каждой гадости, происходящей в IT, есть фамилия, имя и отчество её автора, не будем ударяться в теории заговора и попробуем подобраться, наконец, к теме статьи.
Итак: несколько лет, раздумывая над истоками описанных выше проблем, я никак не мог найти объяснения, почему прекрасные, заставляющие понимать, что ты делаешь, парадигмы вроде TMTOWTDI2 постепенно замещаются их отрицанием5. Почему, реализуя крайне своевременную идею языка с асинхронной парадигмой на борту, добавили полбочки дёгтя — забыли о KISS-принципе3. Будто специально, решили ломать психику неокрепшим умам?
Ну ладно бы только Golang пострадал, но эта фигня теперь везде: возьмём тот же Rust, там — то же самое7! И это, как говорится, — ещё не вечер!
(Всё-таки придётся как-нибудь написать статью с подробным перечнем всех деструктивных поветрий, выплеснуть, так сказать, и заодно припомнить, "что они сотворили с фронтендом"...)
Однако я снова пытаюсь отвлечься. Вернёмся, наконец, к теме.
В общем, у меня долго не получалось найти рациональное объяснение происходящему, но однажды мне его буквально на пальцах растолковал... один из технических топ-менеджеров Яндекс.Такси, где я когда-то работал. История эта уже древняя, потому, думаю, вполне можно рассказать, никого не задев.
С точки зрения IT Яндекс.Такси — это такая компания, где и десять лет назад уже трудился значительный коллектив разработчиков. В то время, когда я там работал, она занималась довольно широким спектром технических задач: автоматизацией собственно такси, разработкой сервисов о еде и прочим...
А, в частности, — наймом водителей, ведь для своей работы бизнес такси требовал целую армию исполнителей, которую различными способами рекрутировали, постоянно преодолевая её естественную убыль.
На то, чтобы организовать найм водителей, компания в те годы ежемесячно тратила приблизительно миллиард рублей. В целом всё было хорошо: миллиард уходит на найм, а (условно) десять — зарабатывается. "Бабки крутятся, прибыль мутится" — все (в том числе собственники) довольны...
Однако в какой-то момент случилось не то чтобы ЧП, но что-то подобное, и в тот раз почему-то не вышло этот самый миллиард на найм выделить. То ли слияние компаний проводили, то ли реорганизацию. В общем, бюджет порезали, и вместо миллиарда выделили всего двести миллионов.
Надо сказать, что решая "сократить этот кост на один месяц", руководство понимало серьёзность и последствия такого действия. Все отдавали себе отчёт, что будет просадка и в следующем месяце обязательно придётся увеличивать расходы.
Но вот беда — просадки не случилось! Месяц закончился, и вообще ни одна бизнес-метрика не пострадала: наняли ровно столько же, сколько в предыдущем.
Видя это, бизнес, разумеется, задался вопросом: "А стоит ли вообще каждый раз впихивать в этот найм по миллиарду? Может быть, и двухсот миллионов достаточно?"
Поскольку речь шла о сумасшедших суммах, то в срочном порядке собрали команду, которая должна была помочь понять, что происходит. Таким образом, туда попал и я — как технический исполнитель.
Взглянув на проблему и на техническое обеспечение этого самого найма (заглянув в код, пообщавшись с разработчиками), я сразу предложил чуть доработать рабочие места: операторов кол-центров, педагогов, инструкторов, а также лендинги, добавив в них этакий аналог метрик.
(Метрики в чистом виде не подходили: требовалось разобраться с длинными цепочками, а для этого необходимо было удерживать связи между сущностями.)
В общем, чтобы выполнить нужные замеры и подсчёты, я решил взять любую базу данных (например, PostgreSQL) и записывать в неё происходящие события вместе с идентификаторами (будущих) водителей, операторов и т.п. Подождав месячишко, пока накопится статистика, я планировал поделать из неё выборки, отвечающие на вопросы бизнеса.
Просто же всё? И вот пришёл я с этим "просто" к тому самому топу.
— Здесь достаточно одного программиста, — начал я, — он за день (ну, хорошо, округлим до недели) сделает функцию, записывающую событие в БД. Большого количества полей в записях не требуется: тип, время, связь с нанимаемым водителем и связь с исполнителем. В общем, работа очень простая, могу даже сам запилить: тут строк пятьдесят кода. Затем, — продолжил я, — мы обойдём все формы и бакенд, добавляя http-запросы, генерирующие это событие, — и вуаля! В конце следующего месяца отчёт готов!
— Не пойдёт.
— Почему?
— Вы не сможете получить разрешение на размещение такого проекта на площадке Яндекса.
— А что тут не так?
— У нас регламент. Например, база данных должна работать в трёх датацентрах.
— Хорошо, запрос к эксплуатации будем делать на постгрис с синхронной репликацией. Что ещё?
— Вы не пройдёте техаудит.
— Что же тут аудировать? Пятьдесят строк кода! Пройдём!
— Нет, — снова повторил он, — то, что ты предлагаешь — ни разу не микросервис. А по регламенту должен быть именно он.
— Хгм... — озадачился я. — А ведь и инфраструктура, которую мы хотим обложить метриками, — не микросервисная.
— Ну и что? Получать ресурсы (БД, деплой) ты будешь для нового проекта, так? Значит, он обязан быть микросервисом, иначе ничего тебе не выдадут.
— Слушай! — попытался я воззвать к его сознательности, — посмотри на бизнес, там ведь все бегают как ужаленные и кипятком во все стороны писают! Речь идёт о судьбе, ни много ни мало, а миллиарда в месяц! Какая разница, микросервис или не микросервис? Давай максимально быстро дадим ответы на поставленные вопросы, а потом будем хоть до пенсии переписывать в спокойном режиме, приводя в соответствие к требованиям регламента?
— Нет, мы не станем так делать! — обломал меня он.
— А как?
— Мы реорганизуем (расширим) отдел. В него войдёт десять-двенадцать разработчиков, они напишут нужные микросервисы. Здесь я вижу что-то около десяти микросервисов.
Собирать статистику мы будем не в базе данных, а в сервисе биллинга, который уже используется в других проектах. Он, правда, для этой задачи не очень подходит... В общем, думаю, года через два сделаем всё необходимое.
— Но бизнес же ежемесячно, возможно, теряет до миллиарда!
— Нас не волнуют проблемы бизнеса. Соблюдение регламентов гораздо важнее!
— А в чём ценность этих регламентов, если за них приходится столько платить?
— Разве много? — удивился он.
— Один человеко-месяц (ограничение сверху) размениваем на двадцать четыре человеко-года (ограничение снизу) плюс, эээ..., двадцать миллиардов потерь за время разработки...
— Ну и что? — задал он вопрос, поставивший меня в тупик.
В общем, хоть задача действительно была на пятьдесят строк кода (вместе с тестами), я не смог его переубедить.
Конечно же, место для деплоя нам не выделили, постгрис тоже не дали. Аудит мы не то что не прошли — мы до него не дошли!
Поняв, что дело здесь тухлое, я спешно ротировался в другое подразделение Яндекса, не обременённое (ещё) подобными регламентами. Ну, а реформированный отдел уже без меня решал эту проблему (насколько я знаю) не два, а почти четыре года. Впрочем, как говорится, это — совсем другая история...
Решение, что нужно оттуда бежать пришло ко мне вместе с пониманием, зачем нужны все эти регламенты. Этот топ и объяснил мне всё, а примерив такую работу на себя, я понял, что "в этой клетке я жить не хочу, да, пожалуй, и не смогу".
Прежде чем двинуться дальше, ещё немного отступлю от темы и сделаю небольшое пояснение о собственно предмете нашего с ним спора.
Технически (именно технически) микросервисы — совершенно бессмысленная вещь.
Микросервисы, например, — не способ масштабировать нагрузку6: stateless программы легко масштабируются простым добавлением копий, а масштабирование statefull всегда происходит там, где хранятся данные.
Можно даже сформулировать правило:
С технической точки зрения (производительность, количество кода и т.п.), микросервис всегда может быть замещён обычным кодом, и это действие приведёт к тому, что накладные расходы упадут, а эффективность вырастет.
Однако зачем их используют, для чего вводят такие регламенты?
— Видишь этих людей? — ответил он мне, показывая страничку одного из подчинённых ему отделов на staff, — здесь, например, их сейчас сто пятьдесят. Все они работают в одной парадигме — пишут микросервисы — причём значительную часть работы вообще делает кодогенератор.
Знаешь, в чём ценность подобного подхода?
— В чём? — переспросил я.
— Во-первых, я могу уволить половину или даже вообще всех, заместив их совершенно новыми людьми с улицы. От этого не случится никакого ущерба.
Во-вторых, никто из них, уйдя отсюда, не сможет сделать систему, аналогичную той, что мы имеем: большинство не то что не знает даже о половине бизнес-нюансов — не имеет представления, чем занимается сосед!
Осмысление
Итак, микросервисы нужны не потому, что дают некий технологический профит, а потому, что позволяют низвести разработчика до уровня мелкого винтика в производственной системе. Быстрая взаимозаменяемость этих винтиков имеет бо́льшую ценность, нежели расходы на разработку.
Это даже не разделение труда, которое предавал анафеме Жан-Жак Руссо, — это самое натуральное отчуждение от результатов труда по Карлу Марксу8!
Ни больше ни меньше!
Отчуждение рабочего в его продукте имеет не только то значение, что его труд становится предметом, приобретает внешнее существование, но ещё и то значение, что его труд существует вне его, независимо от него, как нечто чужое для него, и что этот труд становится противостоящей ему самостоятельной силой; что жизнь, сообщённая им предмету, выступает против него как враждебная и чуждая.
© Карл Маркс
Итак, рассмотрим среднестатистического разработчика Яндекс.Такси. Нанимаясь, он прошёл десяток-другой собеседований9 и попал, наконец, на вожделенную должность. А что дальше? А дальше над ним висит регламент: "только микросервис". И даже больше — "на 80% кодогенерируемый микросервис".
Что такое микросервис, значительная часть которого кодогенерируется? Это способ изолировать разработчика от целого (и друг от друга). Это жёсткий контракт в YAML-файлах: "На входе требуется вот это, а на выходе вот то, приступай!". И даже внутри оставшихся двадцати процентов свобода творчества самым садистским образом ограничена: цензурируется шестью с половиной линтерами!
Поскольку человек — существо разумное, ему присуща потребность самовыражения. И раз она настолько серьёзно ограничена внешними рамками, то неудивительно, что он:
Перманентно пребывает в демотивированном состоянии (отсюда столь низкая производительность: 24 человеко-года, против одного человеко-месяца).
Пытается искать ей иное приложение, пытаясь, например, оптимизировать или улучшить то, что не нужно.
Фрагментарно мыслит (ведь оперирует он именно фрагментами).
В Яндексе есть прекрасный внутренний ресурс (ЯЧан), где можно писать анонимно. Так вот, там эти самые "винтики большой машины" говорят о себе: "Я работаю перекладывателем JSON'ов!"
Шутка? Да, но в каждой шутке всего лишь доля шутки...
А дальше?
Сравнительно длительное время именно в IT мире наблюдалась уникальнейшая (по сравнению с другими отраслями) ситуация: наёмные рабочие имели доступ к средствам производства и в любой момент могли, используя их, прокатиться вверх на социальном лифте.
А что? Всё, что тебе нужно, — компьютер и немножко терпения. Идея же сгодится практически любая, просто сделай качественно!
Однако постепенно такие возможности закрываются и далее будут закрываться ещё агрессивнее. По мере роста отчуждения труд разработчиков будет всё сильнее дешеветь, пока из нынешних хипстеров не получатся настоящие пролетарии.
Уже сейчас бизнес нацелен на радикальное снижение уровня квалификации среднестатистического разработчика, на работника с максимально фрагментированным мышлением (чтобы не пытался, поднимаясь по социальным лифтам, составлять конкуренцию).
Ну а если мышление почему-то фрагментировано недостаточно, то и это ведь исправимо: помимо продвигаемой капиталом профессиональной фрагментации процветают и иные различные симулякры вроде всяких SJW10, BLM и т.п., мешающие человеку разобраться в ситуации, переключающие его из опасного конструктивного русла в безопасное деструктивное.
В итоге весь этот деструктив доводит до того, что некоторые уже добровольно17 устанавливают на свой IDE не только линтеры, контролирующие количество пустых строк, но и форматеры кода!
А затем, эти люди с поломанной психикой начинают доказывать, что вручную прописывать код обработки исключений в каждой функции — благо, что чем строже клетка, в которой их содержат, тем лучше!
Ещё бы! Они уже не помнят, что мир был (или может быть) иным!
Что делать?
Научно-технический прогресс понемногу приводит нас к тому, что именно мы — IT'шники — станем тем рабочим классом, которому придётся ломать систему эксплуатации человека человеком. И делать это придётся, преодолевая уныние и внутреннее лакейское нежелание что-либо менять.
Путь борьбы требует значительных психологических ресурсов, и самое трудное — преодоление собственного нежелания плыть против течения. Хоть это давно описано многими классиками11, но отклик находит лишь у немногих.
...Но иногда некоторые из них говорили что-то неслыханное в слободке. С ними не спорили, но слушали их странные речи недоверчиво. Эти речи у одних возбуждали слепое раздражение, у других смутную тревогу, третьих беспокоила легкая тень надежды на что-то неясное, и они начинали больше пить, чтобы изгнать ненужную, мешающую тревогу.
© Максим Горький.
Именно нам, IT'шникам, необходимо как можно быстрее превозмочь коллективный отказ от борьбы — иначе, как говорил великий американский писатель, железная пята математически непреложна12.
—- Тогда, и вы, и мы, и весь рабочий класс будем раздавлены железной пятой деспотизма, не ведающего удержу и жалости, —- деспотизма, какого не знала доселе ни одна, даже самая тёмная эпоха в жизни человечества. Вот имя для него —- Железная пята!
© Джек Лондон
Начал главу "Что делать?", а о том, что делать, так пока ничего и не сказал. Исправляюсь.
Итак, бороться! А борьба наша начинается прежде всего с воплощения Ленинского завета: "Учиться, учиться и ещё раз учиться"13.
...среди рабочих выделяются настоящие герои, которые —- несмотря на безобразную обстановку своей жизни, несмотря на отупляющую каторжную работу на фабрике, —- находят в себе столько характера и силы воли, чтобы учиться, учиться и учиться, и вырабатывать из себя сознательных социал-демократов...
© В.И. Ленин
Как всегда, учиться придётся именно превозмогая и своё внутреннее нежелание и сопротивление среды.
Боритесь! Отказывайтесь от вакансий, где вам предлагают работать над микросервисами. Встречно предлагайте монолитные приложения!
Удалите из своего IDE форматирующие код расширения, уничтожьте линтеры, верифицирующие стиль, оставьте только те, что дают информацию о возможных ошибках. Заставьте творца, который живёт внутри, выйти на первый план!
Хороший кандидат, для реализации творческих потребностей — OpenSource18. Отчаянно необходимо, например, написать препроцессоры для Go и Rust, реализующие синтаксис исключений!
Изучайте весь стек технологий, а не только тот кусочек, за который вам платят. Чтобы прийти к успеху в деле свержения тирании капитала, необходимо удерживать при себе знания о всех доступных технологиях. Да, всего несколько лет назад понятие "фулстек разработчик" было крайне уважаемым и востребованным, а теперь хедхантер показывает всего одиннадцать вакансий по этому запросу14, против шестисот у "разработчиков микросервисов".
Конечно, это соотношение демотивирует и навевает уныние, но именно оно и показывает направление, в котором нужно двигаться. Направление, в котором находится ахиллесова пята наших врагов.
Вместе с отчуждением уныние и нежелание бороться будут только нарастать, однако нужно помнить, что и шансы на победу со временем уменьшаются. Поэтому, чем раньше мы выступим единым фронтом, тем лучше!
Да, многие возможности уже упущены. Да, Железная Пята наступает с неумолимой неизбежностью. Однако наше генеральное сражение ещё впереди!
Дорогу осилит идущий. Капля точит камень. Если каждый из нас — хоть где-то хоть какой-то гадости в IT — скажет твёрдое "нет!", мир станет лучше, чище и на шажок ближе к идеалу.
Оковы тяжкие падут,
Темницы рухнут — и свобода
Вас примет радостно у входа,
И братья меч вам отдадут.© А.С. Пушкин
Надеюсь, эта статья поможет читателю выбрать правильную сторону в этой вечной борьбе сил света и тьмы. К счастью, или, увы, но отсидеться в сторонке не получится.
Пролетарии всех стран, соединяйтесь!
Литература
Вместо постскриптума (к списку Литературы)
Многие философы (ещё задолго до Руссо) приходили к выводу, что разделение труда неизбежно приводит к тому, что впоследствии Маркс назвал отчуждением.
Но, увы, мало кто предлагал какие-либо конструктивные решения.
Может быть, кому-то будет интересным, но в начале 20 века, творил поистине великий философ и учёный - А.Богданов. Он, в частности, предложил ввести понятие "фулстек-учёного" и добавить науку, объединяющую все прочие.
Его труд — Тектология крайне рекомендуется к изучению. Конечно, это непростое чтиво, поскольку сильно отличается от современного научного стиля изложения.
Основная идея Тектологии состоит в том, чтобы выявлять общие закономерности в совершенно разных науках: общественных и естественных, химии и истории итп, сводя подходы к единообразным...
Чтобы стать хорошим фулстек разработчиком (по Богданову) придётся научиться переносить опыт, накопленный во фронтенде в бакенд. И всё вместе — в системное программирование. Как-то так.
Комментарии (886)
LabEG
13.01.2023 09:32+25А я бы послушал про историю с топ менеджером с точки зрения топ менеджера. Что то в этой былине явно приукрашено.
PS: Микросервисы действительно помогают масштабироваться если умеешь делегировать и распределять труд.
Demacr
13.01.2023 11:52+4Предполагаю что он решал свои задачи: набрать людей, дать ответственное задание сократить издержки. Тут пахнет гигантской ответственностью и премией.
Guenther
13.01.2023 12:37+2Все описанное - не задачи топа, его задачи - определить стратегию, задать тренд и получить вменяемые отчеты о результатах от аналитиков.
PuerteMuerte
13.01.2023 14:41Вы ошибаетесь. Определить стратегию, задать тренд и получить отчёты о результатах, это скажем так, разовая работа. Да, есть некоторые корпорации, где под топом подразумевается чувак, который вообще ничего не делает, и раз в месяц смотрит отчёт о выполнении стратегии, которую он утвердил в начале года. Но обычно топ-менеджмент тесно вовлечён и в тактическое управление, только на более высоком уровне. Грубо говоря, он и принимает решение, по какому пути пойдёт реализация проекта, и даёт распоряжение выделить средства на это, и контролирует выполнение, если проект достаточно важен.
LuchS-lynx
13.01.2023 11:54+1А я бы послушал про историю с топ менеджером с точки зрения топ менеджера. Что то в этой былине явно приукрашено.
Тут недавно была статья - взгляд с другой стороны, выводы там другие, но плач Ярославны о том что в нанимаемых сотрудниках отсутствуют необходимые качества, типа ответственности, присутствует:
https://habr.com/ru/post/709516/
nronnie
13.01.2023 14:26+3Просто история рассказана с точки зрения разработчика (скорее всего очень молодого), который ситуацию дальше "50 строчек кода", который он "может написать за день". Между тем этот код кому-то еще надо потом тестировать, кому-то собирать и развертывать, и кому-то мониторить и сопровождать. И у всех этих "кому-то" вся их существующая инфраструктура может быть (даже скорее всего) уже заточена под определенные шаблоны в которые "написанные за день 50 строчек кода" не влазит.
akakoychenko
13.01.2023 21:36+3Так в это же и прикол. Все ограничения, техаудиты, и прочая херь рассчитана на код, который будет годами работать, поддерживаться.
А автор хотел сделать разовый проект, решить задачу, и потом его выбросить.
Для первой задачи, да, микросервисы затыкают массу дыр. Для второй создают проблемы.
А теперь вопрос, почему не иметь сразу 2 шаблона? Один для Кода с большой буквы, который на годы. Второй для разового маленького кодика на выброс? Лично моё мнение, что потому, что это откроет ящик пандоры. Если такое разрешить, то любой новый проект будут пускать по ветке 2, ибо продакт хочет бонус и медальку, а не ждать 4 года. И, вполне может выйти, что через какое-то время весь новый код будет формально считаться кодиком на выброс ради скорости разработки. Думаю, что очевидно, чем это закончится.
xenon
13.01.2023 23:41Причем если посмотреть "свыше" (а автор ведь говорит не про одну компанию, а в масштабах "мировой революции"), то рыночек отлично решает. Мы тут можем теоретически разное фантазировать, о том как надо или как не надо (не понимая деталей проекта), но очевидно же более общее правило: Как только яндекс будет неэффективно управлять своей службой такси (по любой причине) - на свободном конкурентном рынке тут же открывается ниша, где служба такси может все делать эффективнее и дешевле. И там, где у неэффективного яндекса поездка стоит 500р, у той службы она будет 200р. Потому что у них goto и эксепшены и сервисы правильные. А если же при правильных эксепшнах у них поездка все равно стоит 480р - то так ли важна эта проблема?
gatoazul
14.01.2023 01:19Что на практике подешевело в РФ по сравнению с 2000 годом, благодаря конкуренции именно на российском рынке? Телекоммуникации и западную электронику, естественно, исключаем.
xenon
14.01.2023 02:10+2Современная Россия как эталон для демонстрации рыночных механизмов? Нам до свободного рынка, демократии и капитализма еще оочень далеко. А то, что вы исключили (например, западную электронику) подешевело как раз потому, что там конкуренция есть.
Добавлено:
А вот разве как раз такси - не подходит?
Вообще, вы интересно задали вопрос: "кроме зарубежной электроники" (равносильно, кроме любой). И тут две мысли интересных возникли:Если мы практически все импортируем - то что может у нас подешеветь? Если и подешевеет, то потому что там подешевело.
Мне кажется, очень часто из-за конкуренции не дешевеет, а изначально дешево. Ну вот выходит какой-нибудь новаторский смартфон, в какой-то мере он уникальный (первый смартфон с NFC, например). Но через месяц выйдет конкурент. Поэтому первый смартфон исходно стоит так, чтобы конкурировать с тем, кто только появится в будущем. Поэтому и дешеветь особо не приходится.
Areso
14.01.2023 03:21Хз, на примере Intel/AMD прямо видно, как цены снижаются после выхода И бенчмаркинга конкурентов.
gatoazul
14.01.2023 14:41Вообще-то в РФ - капитализм, причем можно сказать, эталонный. Критерий любой экономической деятельности - прибыль. Критерий неэкономической деятельности (медицина, госуправление, образование) - тоже прибыль. Какой еще вам капитализм нужен?
Что же касается "свободного рынка", то еще неизвестно, правило ли он или исключение.
Каким образом демократия к экономике - вообще неясно.
xenon
14.01.2023 18:36+4В России - госкапитализм, да еще и коррупционный, без равенства перед законом, без контролируемой и сменяемой власти. Мне кажется, вы капитализмом считаете любой бардак, но чтобы создать капитализм - надо еще работать.
Про белорусские креветки слышали же? Вот в капитализме их не бывает. Либо все возят креветки на равных словиях (в идеале), либо никто. В капитализме не оказываются миллиардерами случайные друзья по дзюдо. Это крайне, крайне маловероятное совпадение.
Демократия к экономике очень даже прямым образом. Вот одна не очень демократическая страна сейчас служит прекрасной иллюстрацией, что деньги из нее надо вывозить сейчас, и всегда надо было вывозить,а владываться в бизнес в ней - очень глупо.
ednersky Автор
14.01.2023 18:57В России — госкапитализм, да еще и коррупционный, без равенства перед законом, без контролируемой и сменяемой власти
взять Китай: там государство владеет (в процентах) большим количеством собственности чем Россия. Выглядит это неплохо.
взять США: там коррупция значительно более развита, а местами даже легализована. И ничего. Значительную часть мира строит.
В капитализме не оказываются миллиардерами случайные друзья по дзюдо.
в капитализме именно так всё и оказывается. друзья (реже) или родственники (чаще).
Вот в списке литературы в статье есть произведение Джека Лондона, крайне рекомендую почитать.
Демократия к экономике очень даже прямым образом
вообще никак.
xenon
14.01.2023 22:02+2Китай? Ну вот и приведите любой пример успеха из Китая, только посмотрите всего лишь на 1 шаг глубже, на причины этого (опишите эти причины, как я ниже сделал, причины помогают отличать то, что сделано "благодаря" от того, что сделано "вопреки").
Например, вот для России приведу вам пример. Я отчасти фрилансом зарабатываю (одиночка), отчасти небольшой частный бизнес (небольшая команда). Я сам научился новым технологиям. Сам нашел заказчика. Сам обсудил с ним условия работы, деньги. Выполняю работу. Получаю деньги. Часть денег - отдаю государству. Государство за меня ничего не сделала в этом плане (разве что дало некоторые налоговые льготы на первое время - то есть, так же, собирало с меня деньги, только чуть меньше). Но главное - не помогало. Ни один рубль мне не упал на счет от государства.
Какова роль государства в моем бизнесе? (я могу даже найти конкретные даты и номера указов-законов). Закон о свободе частном предпринимательстве. Закон о внешней торговле (они разрешили мне работать).. Закон о банковской деятельности (благодаря ему я могу переводить деньги. Но переводит мне их другой бизнесмен, банкир, а государство просто разрешает нам, всего лишь не бьет нас палками за это - ну и за то спасибо). Закон об отмене цензуры (иначе, какой интернет может быть?). Везде в моем бизнесе я вижу мой труд и труд других людей (бизнесменов). А упомянутые законы приняты в те самые легендарные "девяностые". С 2000 у меня на виду только один полезный закон - отменены разрешения на мобильные. (Но это опять же, государство не помогло, а перестало мешать). Так что, я знаю, кому в государстве я благодарен, и в какие даты эти действия произошли.
С интересом послушаю, как именно руководящая роль коммунистической партии Китая помогает Xiaomi делать смартфоны и почему их нельзя делать без помощи Партии.
Про легализованную коррупцию, простите, но это оксюморон. У вас какой-то свой, особенный, смысл вложен в это слово.
ednersky Автор
14.01.2023 22:15-1Какова роль государства в моем бизнесе?
примерно такая же как если бы вы открывали бизнес в другом государстве. отличий почти нет.
ну разве что вести бизнес в России гораздо проще чем, скажем, в любой европейской стране.
хочешь таксовать? ~5000 лицензия и вози себе пассажиров. в Париже такая лицензия до 250 тыс евро добирается (у них там что-то вродь аукциона/рынка лицензий)
хочешь на газельке перевозить грузы? Скажем мебель переезжающих людей. регаешь ИП и возишь. упрощёнка или не упрощёнка или даже самозанятость + ИП (без расчётного счёта — вообще бесплатно).
оформляется за день, расходы минимальны.
в США подобный бизнес потребует обязательные расходы на страховку (помимо госпошлин/налогов как у нас) начинающиеся от 50 тыс $ в год.хочешь в германии IT-автоматизацию транспорта запустить? правительство может попросить тебя, ну скажем, построить фонтан в городе. А если не построишь — могут и не одобрить разрешение на занятие бизнесом.
и так всё
PS: всё перечисленное — это из моего опыта. много занимался автоматизацией средств транспорта, ну и близко с этим сталкивался.
xenon
14.01.2023 22:33Ну вот вы привели примеры как разные ограничения от государства мешают бизнесу. Но где же в этом помощь, тем более конкретный китайский пример?
ednersky Автор
14.01.2023 22:37я воспринял ваш текст как жалобу на то, что "в России не оч хорошо", ну и рассказал о своём опыте по другим странам. там всё гораздо сложнее.
чтобы государство именно помогало чем-то заниматься, надо, увы, заниматься чем-то значимым для государства. Это опять же общее для всего мира правило. Россия тут не лучше/не хуже прочих
xenon
14.01.2023 23:00Это хорошо, что там сложнее: значит, бизнесы сворачиваются там, и переезжают к нам. Бизнес ведь не дурак, он денежки считать умеет.
Как по мне, государство не должно помогать (кроме, может, каких-то исключительным случаев, которые не надо путать с правилом). Оно должно создавать условия для равной конкуренции и стараться не мешать. Откатываемся на самое начало ветки про конкуренцию. Если завтра я открываю свою службу такси, задача государства, чтобы я мог открыть ее легко, быстро, дешево. И чтобы гипотетические хулиганы от яндекса мне ноги не переломали и машины не сожгли. (То есть, устанавливать и поддеживать закон). Все. А писать мессенджеры, службы такси, делать банки, газеты, телеканалы и печь булочки - должны уже сами люди.
ednersky Автор
14.01.2023 23:09Как по мне, государство не должно помогать
как по мне так должно.
Оно должно создавать условия для равной конкуренции и стараться не мешать
как может появиться региональный конкурент Google? если без господдержки? никак.
как может появиться скажем производитель медицинского оборудования, при том, что импортное всяко дешевле?
вот кстати интересный бизнес, который государство поддержало, считаю что таких должно быть больше
xenon
15.01.2023 16:28А почему вы не хотите чтобы инвестициями занимались (только не смейтесь сразу, понимаю, что крайне радикальную вещь скажу): ... инвесторы?
Конкурента гугла создавать не надо, он уже есть - поисковик спутник. Все как вы и хотели, с господдержкой. Разве не счастье? Или вы хотите еще спутник-2, спутник-3, и все это на мои деньги (мой бизнес не просит у гос-ва), пока я совсем не сдохну?
А почему в России производить, скажем, медоборудование дороже, чем в швейцарии? Швейцарцу нужно платить 7000 долларов в месяц, русскому 1000 долларов в месяц. Почему швейцарские медицинские компании до сих пор не переехали в Россию, что они говорят?
ednersky Автор
15.01.2023 17:20> А почему вы не хотите чтобы инвестициями занимались (только не смейтесь сразу, понимаю, что крайне радикальную вещь скажу):… инвесторы?
а потому что это не работает.
> А почему в России производить, скажем, медоборудование дороже, чем в швейцарии? Швейцарцу нужно платить 7000 долларов в месяц, русскому 1000 долларов в месяц. Почему швейцарские медицинские компании до сих пор не переехали в Россию, что они говорят?
я представьте знаю почему. приблизительно году в 2003-2004 я работал в компании, которая разрабатывала то самое медоборудование. мы делали софт для агрегата автоматически разбирающего кровь на фракции и делающего какой-то набор анализов.
так вот, стоил этот агрегат — жалкие сто баксов на те деньги, конкуренты (швейцарские и проч) стоили условно двести, но-но-но…
швейцарским и проч… не требовалось лицензирование, а нам требовалось. и чтоб отбить только официальную стоимость лицензий, ну никак не получалось продавать девайс дешевле пятисот баксов.
в итоге — эта разработка ушла на завод в литве и сейчас, до сих пор, в Россию (насколько знаю) продаётся от имени иностранного бренда.
а всё почему? а потому что какие-то кретины в своё время как раз принимали всякие тупые законы на тему «чем свой производитель, лучше импортный»
iig
15.01.2023 21:55какие-то кретины в своё время как раз принимали всякие тупые законы
Кретины - они же не с Марса прилетели? И законы пишутся не просто от фонаря, а с какой-то целью?
ednersky Автор
15.01.2023 22:26> Кретины — они же не с Марса прилетели?
в результате проигранной войны всегда у власти становятся кретины. это закон природы
> И законы пишутся не просто от фонаря, а с какой-то целью?
хорошо хоть ЛГБТ не успели легализовать, а то и это пришлось бы расхлёбывать
iig
15.01.2023 22:46это закон природы
Нет такого закона ;)
хорошо хоть ЛГБТ не успели легализовать, а то и это пришлось бы расхлёбывать
А что такого несправедливого в ЛГБТ? Они как-то по особенному относятся к отчуждению результатов труда?
ednersky Автор
15.01.2023 23:05во-первых, они — такой же безопасный (для капитала) деструктивный (для общества) фактор, отвлекающий народ от конструктивного осмысления ситуации, как и описанные в статье
во-вторых, это просто омерзительно
в третьих, их цель (одна из) или смысл жизни — сообщать всему миру о своих перверсиях,
пруф и цитата:Википедия:
каминг-аут как процесс, который важен для психологического здоровья гомосексуалов
то есть избавиться от них, предоставив им свободу заниматься друг дружкой, нельзя: для их «психического здоровья» им требуется, чтобы они постоянно всех вокруг информировали о том кто они
в четвёртых: это крайне агрессивная секта. если ей не давать укорот, то ещё с глубокой древности имеются свидетельства (которым более 3000 лет), что кончается это тотальной диктатурой ЛГБТ. Остановить подобную диктатуру возможно только силовым способом.И пришли те два Ангела в Содом вечером, когда Лот сидел у ворот Содома. Лот увидел, и встал, чтобы встретить их, и поклонился лицом до земли. И сказал: государи мои! зайдите в дом раба вашего и ночуйте, и умойте ноги ваши, и встаньте поутру и пойдете в путь свой. Но они сказали: нет, мы ночуем на улице. Он же сильно упрашивал их; и они пошли к нему и пришли в дом его. Он сделал им угощение и испек пресные хлебы, и они ели. Еще не легли они спать, как городские жители, Содомляне, от молодого до старого, весь народ со всех концов города, окружили дом и вызвали Лота и говорили ему: где люди, пришедшие к тебе на ночь? выведи их к нам; мы познаем их.
их современная агрессивность подтверждается и тем, что они творят в школах на западе. Уже добрались до смены пола детям 4 лет!
впрочем это всё офтоп.
PS: Если хочется потролить на тему коммунизм и святые писания, то огорчу: как источник знаний коммунисты их не отрицали.
ednersky Автор
15.01.2023 23:16По счастью мы от этого инструмента отчуждения на данном этапе сумели отбиться.
но это всего одно сражение, не война.
iig
15.01.2023 23:20их современная агрессивность подтверждается и тем, что они творят в школах на западе. Уже добрались до смены пола детям 4 лет!
А можно пруф? Только не из соловьёв-ТВ, а первоисточник, чтобы хотя бы на западном языке ;)
ednersky Автор
15.01.2023 23:23на западном языке идите на запад. зачем вы здесь находитесь и общаетесь на восточном?
ednersky Автор
15.01.2023 23:29пруфы легко находятся, эту ветку захламлять не будем.
и пруфы про 4летнего и пруфы про смены пола в школах и большое интервью одного отца, не согасившегося с тем чтобы его несовершеннолетняя дочь сменила пол (по решению школьного психолога), которого за это несогласие посадили (кстати это интервью брали канадские журналисты и оно есть как на русском так на английском). В общем пруфов полно. Здесь, думаю не стоит дальше википедии ходить. Всё-таки это IT ресурс.
iig
16.01.2023 00:04Где-то за орбитой Марса вокруг Солнца вращается обьект в форме чайника. Пруфов полно.
:D
ednersky Автор
14.01.2023 22:41Но где же в этом помощь, тем более конкретный китайский пример?
с Китаем близко не сталкивался, вы, приводя свой бизнес в пример ведь хотели перевести на близкое сравнение? Не могу сказать ничего.
про Китай мы видим только макроэкономические показатели ежегодного развития, которые гораздо лучше многих прочих стран.
при этом, хоть Китай и называют "тоталитарным", а, например, количество зеков там и в абсолютных цифрах (sic!) и в относительных меньше чем скажем в "свободных" США.Кто знает, может быть это как раз следствие приближенности политики государства к среднему человеку? Почему в США так много преступников, что они вынуждены держать по тюрьмам больше народу чем впятеро больший по населению Китай?
xenon
14.01.2023 23:19В Китае - своя "нефть". Их нефть - дешевая рабочая сила (огромное ее количество). Причина их успеха - то, что они приоткрыли (дали свободу) рыночные возможности для работы (выгоднее рыбу от берегов Великобритании везти в Китай, там чистить за копейки, и везти обратно). Плюс, еще где-то с 1970-ых годов распространились дешевые контейнерные морские перевозки (кстати, технология Docker как раз это обыгрывает в своем названии). Именно поэтому возить товары в Китай и из Китая стало дешево.
По мере того, как уровень благосостояния там растет (а расти с низкой базы - достаточно легко) - эта модель бизнеса потихоньку иссякает, уже не хотят чистить рыбу за цент, хотят уже за доллар. И уже приходится что-то думать (аутсорсить в более бедные страны или же механизировать или же возвращать работу своим работникам - к ним хотя бы везти быстрее и дешевле).
Но главное - никакого чуда централизации и тотального контроля там нет. Все всегда и везде создается через свободу (через то, что поводок там чуть-чуть приотпустили).
Если вы видите одновременность события А и какого-то фактора Б, надо понять, это А свершилось благодаря Б или же вопреки Б, установить причинно-следственную связь, а не выдумать ее просто на основании какого-то совпадения. "Моргенштерн выпустил новый хит, вышел новый процессор от Интел - слава Моргенштерну!"
ednersky Автор
14.01.2023 23:23такой "нефтью" обладают сотни государств по миру, а вот рост только у Китая.
выходит дело не (только) в нефти?
xenon
15.01.2023 16:36Конечно. Любой ресурс имеет свою потенциальную максимальную стоимость и реальную. Потенциально - Китаец не хуже швейцарца, мозга у него не меньше, рук тоже. Значит, теми же руками по той же технологии может делать тот же "швейцарский" товар (И у него получится именно швейцарский, в смысле качества. А не китайский). Значит, китайцы могут ориентироваться на медианную ЗП в 7000 долларов. Насколько сейчас недотягивает Китай до этой цены - вот столько и обходится им "руководящая роль компартии".
И Китай - не худшая страна на планете, есть страны, где тоже люди есть, у них тоже 1 голова и две руки, но условия для бизнеса и инвестиций там еще хуже, да.
im_last
15.01.2023 01:28-1взять Китай: там государство владеет (в процентах) большим количеством собственности чем Россия. Выглядит это неплохо.
Так вы же не из будущего прилетели?! Про то каким путем шел Китай и к чему пришел - мы скоро узнаем.
Есть начало, есть середина, есть конец. Ну вот он сейчас в конце середины, а дальше его неизбжно ждет трансформация и вот во что он трансформируется, будет и тем, про что все это было.
То что Китай ведет крайне закрытую политику, по которой толком ничего не понятно, совсем не повод для того, что бы делать очевидные выводы.
Когда вы без смартфона и приложения в нем не можете свободно перемещаться по стране, а на сколько я знаю там именно так. Тогда это, как по мне, максимально дурно пахнущая история. Потому что от средневекового рабства это мало чем отличается, просто кандалы цифровые и условия лучше, но и это может быть временным.ednersky Автор
15.01.2023 01:34+1Так вы же не из будущего прилетели?! Про то каким путем шел Китай и к чему пришел — мы скоро узнаем.
Принесли суровым сибирским лесорубам японскую бензопилу
-
ну-ка, — сказали лесорубы и подсунули ей дуб
-
вжж! — сказала бензопила и распилила дуб
-
хгм, — сказали лесорубы и подсунули ей бетонную шпалу
-
в-жжжжжггггррр! — сказала бензопила и сломалась
-
то-то же! — сказали лесорубы и отправились валить лес традиционным способом
Китай может и опрокинут: подкупив ли элиты, прямым ли военным столкновением, опрокинув ли Россию и заблокировав Китаю все доступы к ресурсам.
если человека убивают ударом кирпича по голове, то факт убийства ничего не говорит о вредности того образа жизни, которого он придерживался
-
im_last
15.01.2023 11:28Выбранная идеология - прямой путь страны в то
светлоебудущее, которое и было выбрано. По этому нет, пример с кирпичем тут не очень.
Политики всегда решают оббирать народ ли и если оббирать, то до какой "нитки". И они же решают, на сколько их граждане будут свободны в правах и свободах.
Если верить тем видео, где стоят очереди с людьми за тем, что бы тебе всунули палку в нос, то лично я не хотел бы жить в такой стране. При том, что никто не доказал то, что вот эти самые палки в нос хоть сколько то эффективны и безопасны сами по себе. Кто знает, что на кончике этих палок может быть?!
ednersky Автор
15.01.2023 12:51+1ваши рассуждения не отличаются от средневекового уровня
только тогда кто-то осуждал шамана или епископа, а теперь вы - тестирование на вирусы
im_last
15.01.2023 19:34Мои рассуждения основаны на понимании того, что с начала 2020 года все происходящее выглядит как одна большая аномалия, которая, как бы не возможна для нашей цивилизации, но все же, каким-то образом, она возникла. И когда ты начинаешь искать закономерности, то понимаешь, что факты начинают говорить сами за себя.
Все эти палочки ничего не дают, потому что и статистика по выявлению ковида ни на что по сути не влияет, ибо можно ее так же вычислять уже по факту поступления больного в больницу. А если лекарства от ковида нет, тогда смысл тестирования в чем? Кроме как в тыкании в нос, получается, другого смысла нет. И если это тыкание, просто для того, что бы "закрутить гайки", тогда - пол беды, но может быть и не только для этого.
gatoazul
15.01.2023 12:58вы капитализмом считаете любой бардак
Я считаю капитализмом ровно то, что написано в любом учебнике политологии, включая западные. Капитализм - это экономико-политическая система, в которой главным критерием экономической деятельности является прибыль. РФ прекрасно под это определение подходит, даже с избытком.
Если вы считаете капитализмом только райские рекламные картинки, то это исключительно недостатки вашей когнитивной картины мира.
xenon
15.01.2023 16:39Похоже, в мире более одного учебника, и в них даже немного разные определения...
gatoazul
15.01.2023 13:03Вот в капитализме их не бывает. Либо все возят креветки на равных словиях (в идеале), либо никто.
Вы написали ерунду. Заградительные пошлины и другие меры ограничения импорта применялись в самых что ни на есть капиталистических странах, причем постоянно и активно.
Более того, именно с помощью таких мер развитые страны и строили собственную экономику.
Для вашего дальнейшего просвещения: https://www.amazon.com/Bad-Samaritans-Secret-History-Capitalism/dp/1596915986
xenon
15.01.2023 16:43При чем тут заградительные пошлины? Я не о них, а о равенстве перед законом. Каким-то образом получается так, что возить европейские креветки в Россию нельзя, но для друзей "кого надо", в Беларуси появилось море-океан со своими креветками, а таможенная служба не видит в этом никакого подвоха.
0xd34df00d
14.01.2023 19:57-1Так все же с чего вы взяли, что критерий капитализма — прибыль, а не упомянутые мной в соседнем треде свободы?
gatoazul
15.01.2023 13:07Откройте любой учебник политологии, можно западный. И прочитайте определение.
P.S. Больше всего свобод было в первобытном обществе.
0xd34df00d
15.01.2023 18:44Дайте ссылку на легко доступный (чтобы мне в библиотеку за бумажной версией идти не пришлось) — обсудим.
nronnie
14.01.2023 09:17А автор хотел сделать разовый проект, решить задачу, и потом его выбросить.
А автор не думает, что без "все ограничения, техаудиты, и прочая херь" его разовый проект может обвалить кучу всего другого и принести больше убытков чем должен был бы принести выгоды?
Разовый код годится там, где кроме тебя и еще полутора калек его никто не использует и от него ничего больше не зависит.
gandjustas
13.01.2023 17:08+3Он расскажет о гигантской сложности систем и куче связности, которую можно победить только микросервисами.
Потому что менеджер тем важнее, чем больше у него людей в подчинении. Если он упростит архитектуру и оставит 15-20 человек вместо 150, то его политический вес в компании сократится в примерно во столько же раз.
А регламенты ему помогают бороться с теми, кто может работу сократить.
MentalSky
13.01.2023 17:27+2дай волю этим инженерам - никакого бизнеса не станет (с) чье-то
сказано было про ситуацию, когда инженер стремится упростить и автоматизировать (хочет решить задачу), а манагер - усложнить и повысить стоимость (цель не решить задачу, а через процесс ее решения достичь каких-то еще целей)
nronnie
13.01.2023 09:35+52Всю статью, похоже, надо в раздел "юмор".
необоснованное суждение "о вредности оператора goto"
Пишу на C# c 2005 года, недавно поймал себя на том, что не могу вспомнить а есть ли там оператор "goto" вообще. Даже в документацию полез из любопытства. (Оказалось, что все-таки есть).
Заставьте творца, который живёт внутри, выйти на первый план!
За 15+ лет разработки уже з*ся половину если не больше рабочего времени не работать, а разбираться во всевозможном творчестве творческих творцов.
xmetropol
13.01.2023 10:20+14Я понимаю, что для перекидывания Json'ами между микросервисами оператор goto не нужен, собственно потому некоторые разработчики о нём и не слышали. Но для того, чтобы такие разработчики могли перекидывать свои Json'ы максимально быстро, другим разработчикам приходится терпеть боль от использования такого "плохого" инструмента и скрепя зубами писать код используя его, т.к. по-другому скорости не получить. Возможно для Вас они не авторитет, они всего-лишь разрабатывают dotnet:
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Text.Json/src/System/Text/Json/Reader/Utf8JsonReader.csСлабонервным лучше не открывать, 60 операторов goto в 1-м файле.
auresio
13.01.2023 10:35+7Человеку свойственно хейтить то что он не понимает/не умеет пользоваться. Возможно оператор goto просто не для всех. Я использовал его буквально пару раз в своей жизни, и не считаю его чем то из дьявольских вещей, но общество видимо склонно округлять и срезать уточнения получая цепочку "оператор goto выручает, но если вы будете использовать его неосторожно получите по лбу" => "goto бьет людей" => "goto не должен существовать". Последней стадией начинается плохое отношение и отлучение от процесса раработки тех кто его использовал успешно или просто нейтрально к нему относится.
auddu_k
13.01.2023 12:26+2Конечно он нужен, как нужно многое другое из неиспользуемого, точнее из не часто используемого. Важно, чтоб каждое применение было осознанным и ожидаемым.
Получается ещё во времена Дейкстры была проблема
с творцамисо стремлением захламления кода, когда кажется, что лучше совсем запретить, чем дождаться момента невозможности использования.
12rbah
13.01.2023 10:40+10Конкрентно по вашей ссылке, очень легко понять зачем там нужен goto(по первым 10 штукам по крайней мере), по сути это и есть один из вариантов правильного его использования, еще вариант правильного использования на мой взгляд - это выйти из вложенного цикла, хотя иногда для этого есть отдельный механизм в языке.
боль от использования такого "плохого" инструмента
Вроде автор коммента ругает не goto, а призыв к творчеству а коде, в целом не случайно придумали линтеры и прочие штуки для стандартизации, не очень приятно в коде видеть имена переменных типа таких _Cammel_caseVar_DATA_SOURCE или что человек где-то пишет if в одну строчку а где-то такойже if в 4 строчки или кто-то внезапно решил написать свой парсер json-a, т.к. он творец, но допустил в нём ошибку, я думаю автор коммента больше говорил про такие штуки
xmetropol
13.01.2023 10:52Так я и не критиковал автора комментария. Но если писать 17 лет на C# и ни разу не сталкиваться с goto, то может просто круг решаемых задач не требовал знания такой вещи, как goto. Допустим я в своей практике занимался "творческими" задачами и приходилось пользоваться этим оператором. Возможно когда-нибудь моё творчество тоже кто-то раскритикует, назовёт код лапшой и перепишет все без goto, заодно уронит производительность какого-нибудь "творческого" алгоритма раз в 10. По поводу goto в dotnet можно ещё вот так посмотреть:
https://github.com/search?l=C%23&q=org%3Adotnet+goto&type=Codeно это уже совсем для смелых.
maeris
13.01.2023 17:29назовёт код лапшой и перепишет все без goto
Тут немного другой ход мыслей должен быть, чтобы решать проблему правильно:
goto это низкоуровневая операция
люди не умеют постоянно думать низкоуровневыми операциями
иногда бывает код, где абстракция, которая позволяет не пользоваться низкоуровневыми операциями, протекла и не работает (например, роняет производительность)
если мы воспользуемся низкоуровневой операцией руками, потому что знаем, что здесь она работает, лучше не станет, потому что сломаются типизация, кодтрансформеры, линтеры и коллеги
нужно починить абстракцию: ещё разок поискать какие-нибудь альтернативные фичи в ЯП, которые позволяют записать эти goto без просадки производительности (какие-нибудь там named break/continue, return, генераторы и т.п.), а когда совсем не останется вариантов, сделать кодогенератор, который генерирует код с goto.
nronnie
13.01.2023 11:39+17Я посмотрел в один метод, в котором 10 goto. Которые вообще не нужны. Они все ведут на две метки в конце файла:
Done: return retVal; ReadFirstToken: retVal = ReadFirstToken(first); goto Done;Почему вместо
goto Done;нельзя написатьreturn retVal;а вместоgoto ReadFirstToken;return ReadFirstToken(first);для меня загадка.
yasha_akimov
13.01.2023 12:54+10Ага, и ещё парочку примеров правильного использования goto:
Done: return ConsumeTokenResult.Success; IncompleteNoRollback: return ConsumeTokenResult.IncompleteNoRollBackNecessary; IncompleteRollback: return ConsumeTokenResult.NotEnoughDataRollBackState;return true; IncompleteRollback: return false;Несомненно, если переписать это творчество без goto, то оно потеряет 90% производительности
ednersky Автор
13.01.2023 12:58Вот этот код (первый попавшийся модуль в ядре) как ни переписывай без goto - всегда будет хуже, чем с goto.
yasha_akimov
13.01.2023 13:15Ну вообще для таких целей можно использовать менеджер контекста. Но увы, упираемся в возможности языка.
ednersky Автор
13.01.2023 13:17-1вы имеете ввиду аналог with из мира питона?
но там получается крайне многословная конструкция, и возникает вопрос: зачем она нужна? Только чтобы избежать
goto?yasha_akimov
13.01.2023 13:20+2Менее многословная чем вариант с goto, но с большим уровнем вложенности.
Да, коммент был исключительно про то, чтобы показать, что современные подходы достигли и превзошли уровень выразительности, который раньше можно было достичь через goto
euroUK
13.01.2023 15:36+1А какая разница, если в байткоде все равно будет какой-нибудь JMP?
PuerteMuerte
13.01.2023 16:43+3Борьба с goto — это не про отсутствие безусловных переходов в программе, а исключительно про читабельность и сопровождаемость высокоуровневого кода.
yasha_akimov
13.01.2023 17:28+1Так цель выпилить goto из кода, а не jmp из машинного кода. Когда у тебя есть менеджер контекста, ты его написал в одном месте и переиспользуешь во всех остальных местах. Сразу же избавляет то того, что кто то забыл вызвать завершающую функцию или перепутал их порядок. Плюс читаемость, плюс надежность. А то что компилятор потом его преобразует в тот же jmp, так это же хорошо, минимум накладных расходов значит.
ednersky Автор
13.01.2023 17:32чтобы использовать менеджер контекста (например в python) нельзя просто так взять и написать его один раз.
Нужно каждый раз определять объект с методами__enter,__exit,__aenter,__aexit
Zagrebelion
13.01.2023 18:55Можно взять декоратор contextlib.contextmanager, который обернёт любой метод в класс с нужными дандерами.
amishaa
13.01.2023 13:25Как минимум от err_pm и err_out избавится не составляет труда, на эти теги ровно по одному условному переходу, можно остальной код унести в else.
Как, кстати, и err_clk.
Т.е. на стандартных if/else оно выглядит вот так:static int amba_read_periphid(struct amba_device *dev) { struct reset_control *rstc; u32 size, pid, cid; void __iomem *tmp; int i, ret; ret = dev_pm_domain_attach(&dev->dev, true); if (ret) { dev_dbg(&dev->dev, "can't get PM domain: %d\n", ret); } else { ret = amba_get_enable_pclk(dev); if (ret) { dev_dbg(&dev->dev, "can't get pclk: %d\n", ret); } else { /* * Find reset control(s) of the amba bus and de-assert them. */ rstc = of_reset_control_array_get_optional_shared(dev->dev.of_node); if (IS_ERR(rstc)) { ret = PTR_ERR(rstc); if (ret != -EPROBE_DEFER) dev_err(&dev->dev, "can't get reset: %d\n", ret); } else { reset_control_deassert(rstc); reset_control_put(rstc); size = resource_size(&dev->res); tmp = ioremap(dev->res.start, size); if (!tmp) { ret = -ENOMEM; } else { /* * Read pid and cid based on size of resource * they are located at end of region */ for (pid = 0, i = 0; i < 4; i++) pid |= (readl(tmp + size - 0x20 + 4 * i) & 255) << (i * 8); for (cid = 0, i = 0; i < 4; i++) cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) << (i * 8); if (cid == CORESIGHT_CID) { /* set the base to the start of the last 4k block */ void __iomem *csbase = tmp + size - 4096; dev->uci.devarch = readl(csbase + UCI_REG_DEVARCH_OFFSET); dev->uci.devtype = readl(csbase + UCI_REG_DEVTYPE_OFFSET) & 0xff; } if (cid == AMBA_CID || cid == CORESIGHT_CID) { dev->periphid = pid; dev->cid = cid; } if (!dev->periphid) ret = -ENODEV; iounmap(tmp); } } amba_put_disable_pclk(dev); } dev_pm_domain_detach(&dev->dev, true); } return ret; }ednersky Автор
13.01.2023 13:32+1стал ли код лаконичнее? нет
стал ли он эффективнее? хз
а избавиться от goto можно
amishaa
13.01.2023 13:35+5Он не стал менее лаконичным. Он вряд ли поменял эффективность (потому что переходы дословно те же). Зато все условные переходы, по которым можно прийти на err_clk видны из структуры кода (а не из его чтения).
ednersky Автор
13.01.2023 13:37+1Он не стал менее лаконичным
совершенно точно стал. теперь в коде больше строк, теперь длина этих самых строк тоже выросла
CodeRush
13.01.2023 14:32+4Тогда давайте заменим в оригинальном коде все вхождения повторяющегося паттерна
if (assertion_evaluating_to_true) { error_handling(); goto cleanup_label; }
На широко известный в узких кругах макросrequire_action(assertion_evaluating_to_false, cleanup_label, error_handling());
Код станет короче, понятнее, и «голого» goto для обработки ошибок там больше не останется, т.е. если goto там таки появится — он начнет намного яростнее бросаться в глаза, и все такие места можно будет найти грепом, и при этом не нужно будет отделять обработку ошибок от выходов из глубоких вложенных {} и т.п.
sappience
13.01.2023 23:59Хрен с ней, с длиной строк. Код стал менее читаемым. При каких условиях выполняется строка X? Надо добраться до начала блока, ага перед началом блока else, значит надо еще один блок промотать вверх до if. Но этот if вложен в другой else... Это какая-то "Игра в классики" Хулио Кортасара, а ведь изначальный листинг читался сверху вниз как линейный текст.
amishaa
14.01.2023 14:37+1Так переходы не поменялись - конкретная строчка кода раньше и теперь выполняется при одних и тех же условиях, просто раньше из кода было неясно, сколько предварительных условий проверяется, а теперь видно.
xmetropol
13.01.2023 14:16Результат выполнения будет абсолютно одинаковым. Но я не могу взглянув на этот код с уверенностью в 100% сказать, что после замены goto на return даже в этих местах компилятор в итоге выдаст абсолютно одинаковый asm код. Чтобы ответить почему именно разработчики оставили в этих местах goto, нужно скомпилировать и смотреть в дизассемблер и делать бенчмарки. Я не думаю, что код, который парсит все Json в Asp.Net Core сервере писали глупые люди. У них 100% есть куча бенчмарков для этого кода, который запускался тысячи раз на разных архитектурах. Возможно есть причина в этих goto, и выигрыш даже 0.5% на ровном месте стоит чуть больше "красивого" кода. В противном случае, почему бы не открыть PR в кодовую базу dotnet и не предложить им улучшить читаемость кода и понимание control flow?
maeris
13.01.2023 17:34-1Потому что все эти ваши return ReadFirstToken займут больше места в байткоде (и в ассемблере, когда код откомпилируется), протянутся в кеш цпу, вытолкнут из него обрабатываемый текст, и просадят производительность. Конечно, я не проверял (и вообще на C# не пишу), но на других ЯП парсеры писал, и там компактность кода парсера (особенно если lookahead не ограничен и бывает большим) весьма важна.
0xd34df00d
13.01.2023 19:07В таких случаях доверять компилятору все равно нельзя, и надо писать кодогенератор руками (хоть с
gotojmp, хоть с чем угодно).maeris
14.01.2023 12:19Кто ж спорит, я тут рядом коммент об этом и написал. Здесь-то речь шла о том, почему нельзя везде просто сделать return.
DmitryZlobec
13.01.2023 11:53Слабонервным лучше не открывать, 60 операторов goto в 1-м файле.
У Дейкстры AFAIK претензия к использования GOTO только в качестве оператора безусловного перехода. В том же RISC-V вызов функций делается через инструкцию JAL, JARL (jump and link). Если у вас нет стека, то без goto вам никак.
ednersky Автор
13.01.2023 13:00-1goto не бывает безусловным. этот оператор всегда размещают в каких-то частях кода, при том что попадание туда ограничено массой условий.
конечно можно писать в самом начале функции `goto label`, но зачем?DmitryZlobec
13.01.2023 15:41+2Зависит от языка: на ассемблере сплошь и рядом. Например jump label в самом начале памяти ставится для перехода на entry point, так как перед ней как правило идет таблица векторов прерываний, а процессор стартует не с нулевого адреса. Также это будет использоваться если у вас жестко зашиты адреса, например для немаскируемых прерываний, а новый код туда просто не помещается. Тогда будете уходить по jump и возвращаться. И как я уже сказал выше, Вы исходите из того что в системе есть стек куда сохраняются адреса возвратов функций. Уберите из системы стек и останется только goto. Но конечно можно сказать ассемблер - не ЯП.
WraithOW
13.01.2023 17:16+2Три раза ха. Олдовый ассемблерный goto - это восхитительная в своей хтони вещь, которая позволяла вам, к примеру, телепортироваться из середины одного метода в середину другого, позволяя им шарить куски кода без вынесения их в независимые подпрограммы.
maeris
13.01.2023 17:39Бывает. Например, при имплементации far jump линковщик раньше мог сделать goto на другой goto :)
MonkAlex
13.01.2023 10:28И исключения в шарпе тоже есть. И всем этим можно пользоваться, никто в шарпе не заявляет, что это антипаттерны.
Автор перегибает =)
roboter
13.01.2023 12:59+1Прям антипаттерн не заявляют, говорят exceptions are expensive
DistortNeo
13.01.2023 13:23Ага, меня это в какой-то момент настолько выбесило, что я в итоге написал свой велосипед для работы с сокетами.
Если кратко, то при неблокирующих операциях с сокетами постоянно бросаются исключения (EWOULDBLOCK, EINPROGRESS и т.д.), которые на самом деле не ошибки, а просто штатная работа API. Из-за этого при подключённом отладчике в debug-сборке производительность падала до пары десятков IOPS. Без отладчика было чуть лучше, но все равно критично.
P.S. Возможно, сейчас дела с этим немного лучше, но тогда это были времена Mono, когда .NET Core только появлялся.
astypalaia
13.01.2023 12:18+12у нас один разработчик как-то начитался о вреде "goto" и стал вместо "goto" писать "throw SUCCESS", в продукте все исключения логируются, мы долго потом думали, что означают в логе записи: Exception: operation completed successfully.
Уж лучше бы он писал "goto"
auddu_k
13.01.2023 12:22+2Разбираться в творчестве творцов - шедевр )
Сразу лайк и подписка, видно родственную душу ????
xenon
14.01.2023 00:00Мне кажется, это частый случай, когда исключение воспринимается как правило.
Правило в том, что с goto обычно все плохо. Но... иногда в рубрике "программисты шутят" появляется какая-то интересная задача, которая с goto решается изящнее, чем-то лучше. Такое бывает, верю. Но надо понимать, что это исключение.
Или вот термины "военная хитрость" и "боевой дух" (то, чему меня последний год чтения новостей научил) - конечно же лучше, когда есть высокий боевой дух. Но как мы видим, не слишком он помогает. Похоже, ракеты-пулеметы тоже имеют некоторое значение, а боевой дух - скорее дополнение, хорошее, полезное, но не такой значимое, как показано в детских книжках и фильмах.
Или, помню множество историй о том, какой "дутый" ВВП в развитых странах: мол, можно один и тот же товар пятьсот раз перепродать, ВВП по цифрам будет большой, а по факту никакой. И да, это тоже верно, так же, как полезность goto в редкой задачке. Полезное исключение, которое хорошо бы знать, понимать, и не забывать, что оно - именно исключение.
Вообще, мне кажется, правила важны только в детстве, когда ты их еще не знаешь. А в более взрослом возрасте правил знаешь даже больше, чем нужно и гораздо важнее понимать, как эти правила "пересекаются", какое правило важнее другого, где границы применимости каждого правила.
ednersky Автор
14.01.2023 00:02Но надо понимать, что это исключение.
ядро OS - исключение
парсеры - исключение
стейтмашины - исключение
итп
minisotm
13.01.2023 09:36+32то Вы ругаете тех, кто хейтит goto, то сами безапелляционно ругаете микросервисы. Нет ничего плохого ни в том, ни в другом. Каждой задаче- свой инструмент, плоха крайность.
ednersky Автор
13.01.2023 09:37-8goto - технологический инструмент
микросервисы - инструмент организации труда (ну или отчуждения, если по Марксу)
это разные сферы, одна - IT'шная, другая - вне-IT'шная.
как-то так
12rbah
13.01.2023 10:41+26ну или отчуждения, если по Марксу
При чём тут отчуждение труда вообще? В монолите человек также пишет свой модуль и не может написать свою систему один и с нуля.
auddu_k
14.01.2023 23:20IT не существует вне бизнеса, какое бы технически классное решение ты не предложил, если затраты будут выше возможного, бизнес загнётся и решение будет никому не нужным. Оно останется классным, но мертвым.
Именно потому микросервисы - наше будущее ????♂️
Ztare
13.01.2023 09:37+24Автор решил много набросить на вентилятор
1. Goto - причины не в авторитете, разработчики согласны с доводами, они очевидны, проверены и логичны. Поэтому требование по неиспользованию возведено в абсолют, неудобства его отсутствия ничтожны на фоне преимуществ когда программисты никогда им не пользуются. Вопрос к автору - что вам не понятно в этих доводах и причинах "табу" на goto? Вы писали сколько-нибудь сложные проекты где он используется как значимый способ управления потоком вычислений, а не в 1 месте?
2. Про динамическую типизацию - аналогично причины почему разработчикам не нравится опять же известны, широко обсуждались, крупные коллективы разработчиков осознали проблемы и всячески стремятся типизировать проекты. Проблемы на этапе написания кода - подсветки синтаксиса, валидации и автодополнения кода. Проблемы на этапе исполнения - ошибки типов в рантайме, накладные расходы на динамическую типизацию. Вопрос к автору - вы разрабатывали сколько-нибудь крупные и\или нагруженные проекты с динамической типизацией? Вам непонятны аргументы или у вас есть чем их ультимативно перебить?ednersky Автор
13.01.2023 09:39Вы писали сколько-нибудь сложные проекты где он используется как значимый способ управления потоком вычислений, а не в 1 месте?
я писал модули для ядра Linux. однако я в дисклаймере написал, что спорить по частностям не буду. Загляните в исходники ядра и убедитесь, что код с зависимой инициализацией безgotoбудет значительно менее читабеленZtare
13.01.2023 11:18+6Именно по этому есть оговорка про значимость - то что приведете 1 пример из проекта на несколько миллионов строк кода Linux. Запрет GOTO возник когда в языках было принято строить на нем почти все управление выполнением кода. Это сейчас языки и подходы развились и приспособились (ввиду запрета на GOTO) - появилось множество удобных и понятных замен GOTO, изменились подходы к структурированию кода
0xd34df00d
13.01.2023 19:13+6Я бы не стал по сишке делать выводы о том, что в любом языке без goto никуда.
12rbah
13.01.2023 09:46+6Про динамическую типизацию
Не уверен на 100%, но мне кажется что довольно много людей не понимает того, что если писать средне-крупный проект, то для проверки работы сервиса/программы придется писать либо много хороших тестов, которые будут проверять работу и то, что типы переменных можно безопасно использовать, либо долгую отладку приложения.
ednersky Автор
13.01.2023 09:48кстати очень часто (см. обсуждения на хабре) аппологеты типов именно противопоставляют их тестам.
12rbah
13.01.2023 10:07+3Тестировать нужно в любом случае, просто если язык типизированный то обычно это значит только то, что будет значительно меньше проблем с типами. А например для тесты для проверки работы парсера url, придется писать в любом случае независимо от того на каком языке он был написан.
ednersky Автор
13.01.2023 10:09+1просто если язык типизированный то обычно это значит только то, что будет значительно меньше проблем с типами
а проблемы с типами не составляют и 1% всех возникающих на стадии тестирования проблем. вот я о чём
Cerberuser
13.01.2023 10:17+9NullPointerException - это в некотором смысле тоже "проблема с типами", например (точнее, с тем фактом, что nullability никак в этих типах не выражена). Их тоже "менее 1%"?
12rbah
13.01.2023 12:18+3а проблемы с типами не составляют и 1%
Может я мало пишу на таких языках, но довольно часто встречаюсь с такой проблемой, и они составляют явно не 1%. Думаю многие просто не обращают внимания на эту проблему, т.к. часто ошибку можно увидеть довольно быстро. Особенно неприятно она тогда когда случайно можешь присвоить новые данные уже существующей переменной, которая например раньше была объектом, а стала примитивом или наооборот.
ednersky Автор
13.01.2023 12:39проблемы с типами это когда вместо килограмм случайно в формулу прислал километры.
такое да, иногда бывает, но это от явного непонимания "а что же такое я делаю". И такое очень легко выявляется тестами, поскольку является грубой ошибкой.
ksbes
13.01.2023 12:49+7Если такое происходит только в первую пятницу тринадцатого високосного года — то даже самые паронаидальные тесты скорее всего не помогут (у меня на практике случались баги подобной редкости). А система — упадёт. И хорошо, если это будет форум с котиками, а не система предотвращения смещивания ненужных веществ на химическом заводе.
А вот система типов гарантирует отсутствие ошибок типов. Т.е. не 99.99%, а ровно 100%. С этой стороны — точно не прилетит. Это многого стоит!ednersky Автор
13.01.2023 12:53+1А вот система типов гарантирует отсутствие ошибок типов.
ничего она не гарантирует. возьмём пример на GO приведённый в статье и предположим, что foo и bar возвращают РАЗНЫЕ типы ошибок.
что сделает программист в первую очередь?
приведёт к одному типу, аггрегирующему обе ошибки (
enum,structне важно). А с этого момента ваша система типов перестаёт что-либо гарантировать.и ещё раз повторюсь: ошибки вида "вместо километров прислали килограммы" - крайне редкие, возникают только от тотального непонимания "а что же такое я делаю?"
XelaVopelk
13.01.2023 14:08+5Если он осознанно скастует разные типы ошибок к агрегирующему типу ошибок - он берёт на себя отвественность за это. Но при этом он будет точно знать, что ему прилетит на вход агрегации ошибок точно типизированная ошибка, а не строка "ой больно мне больно".
12rbah
13.01.2023 14:52foo и bar возвращают РАЗНЫЕ типы ошибок.
Есть стандартный тип error, которым используется в 99% случаев, и поэтому никто не кастует ошибки в обычных проектах(хз зачем это вообще делать в го).
"вместо километров прислали килограммы"
В большинстве случаев, это обычная невнимательность, но это по моему опыту, возможно у вас всё по другому.
ednersky Автор
13.01.2023 15:08Есть стандартный тип error, которым используется в 99% случаев, и
поэтому никто не кастует ошибки в обычных проектах(хз зачем это вообще
делать в го).(просто Rust под рукой и свежее в голове, потому пример не Go, а Rust)
Вот например берём библиотеку
yaml-rust- она возвращает свои ошибки, аstd::- свои. И это логично: раз язык типизированный, то возвращая более одной ошибки нужно разделять их по типам (иначе машинно обработать их будет сложно).Ну и соответственно, поскольку разработчики НЕИЗБЕЖНО сталкиваются с проблемой машинообрабатывания ошибок, то они вынуждены вводить новые их типы.
А другие разработчики, которые пишут код которому "не важно какая ошибка, если она есть - передать её вверх по стеку" (99.9% кода) - мучаются с объединением всех встреченных типов.
При том, что этим мог бы заниматься компилятор
ksbes
13.01.2023 15:19мучаются с объединением всех встреченных типов
А для этого есть наследование и, если очень надо, рефлексия. Error есть Error.
А другие разработчики, которые пишут код которому «не важно какая ошибка, если она есть — передать её вверх по стеку»
А вот это да — меня тоже коробит. Только начал экпериментировать с Rust'ом — там наверняка же есть методики вроде ленивой цепочки или что-то в этом роде, которая позволяет это делать автоматически. Есть же?
ednersky Автор
13.01.2023 15:21есть - знак вопроса.
`foo = bar()?`
эквивалентно - ошибку передать по стеку выше, ну а если её нет - присвоить foo.
Но для этого и нужно соединить все ошибки в один тип
Cerberuser
13.01.2023 16:40+4А другие разработчики, которые пишут код которому "не важно какая ошибка, если она есть - передать её вверх по стеку" (99.9% кода) - мучаются с объединением всех встреченных типов.
Или берут что-нибудь типа thiserror, пишут простенький тип, вешают аннотацию и возвращаются к бизнес-логике, потому что компилятор при помощи этих аннотаций может заниматься много чем.
ednersky Автор
13.01.2023 16:44-3Или берут что-нибудь типа ..., пишут простенький тип, вешают аннотацию и возвращаются
а могли бы вместо этой сибурды заниматься полезным делом, например лишний тесткейз описать
0xd34df00d
13.01.2023 19:17+4ничего она не гарантирует. возьмём пример на GO приведённый в статье
У го очень слабая система типов, я не понимаю, какие выводы об общем случае вы хотите по ней сделать. Да и вообще, делать выводы об общем случае по одной частности — странно.
Хотя, конечно, более корректным утверждением было бы «достаточно строгая система типов гарантирует отсутствие данного класса ошибок», и в пределе вам вообще не нужно тестировать ваш код (кроме, возможно, части, общающейся с внешним миром, но и там можно фигакнуть property-based-тесты, чтобы убедиться, что внешний мир соответствует вашей модели внутри вашего кода).
и ещё раз повторюсь: ошибки вида "вместо километров прислали килограммы" — крайне редкие, возникают только от тотального непонимания "а что же такое я делаю?"
А вместо километров присылать метры или футы — уже почаще бывает.
ednersky Автор
13.01.2023 20:05-1достаточно строгая система типов гарантирует отсутствие данного класса ошибок
тут ошибка
не гарантирует
гарантирует бОльше телодвижений, требуемых к совершению программистом, соответственно чуть меньше ошибок такого класса.
Однако открытый вопрос: а стоит ли овчинка выделки?
Очевидный ответ - не стоит
0xd34df00d
13.01.2023 20:17+1В чём ошибка? Во-первых, по самой структуре высказывания она это гарантирует. Система типов C++ гарантирует (здесь и далее — в отсутствие явных хаков), что вы не передадите строку туда, где ожидается число. Система типов раста гарантирует, что у вас не будет некоторого класса гонок. Система типов хаскеля гарантирует, что если в функции не написано, что она модифицирует глобальное состояние, то она его не модифицирует.
Более того, есть системы типов, где можно сформулировать (и доказать) произвольное утверждение о коде. Поэтому система типов агды гарантирует вообще что угодно.
Однако открытый вопрос: а стоит ли овчинка выделки?
Стоит. Я предпочту хаскель какому-нибудь сишарпу или, тем более, питону без особых сомнений.
ednersky Автор
13.01.2023 20:20-5В чём ошибка?
в том, что НЕ гарантирует.
Гарантирует = это про 100%.
найдя один контрпример мы делаем высказывание невалидным. У вас оно невалидно. (пример выше приведён)
0xd34df00d
13.01.2023 20:32+5Ещё раз, тезис: достаточно мощная система типов гарантирует отсутствие ошибок определённого класса. Что именно вы опровергли контрпримером, и где в этом контрпримере доказательство достаточности?
Более конкретный тезис: агда позволяет гарантировать отсутствие любых ошибок в логике кода, которые можно сформулировать на языке математики1 и которые не связаны непосредственно с внешним миром2.
1 конструктивной логики высшего порядка, если конкретно.
2 например, нельзя гарантировать свойства, завязанные на особенности работы условного postgresql, но можно гарантировать свойства, завязанные на формализованную внутри языка модель sql-движка. Соответствие модели реальному движку придётся проверять иначе.
ednersky Автор
13.01.2023 20:33-9Ещё раз, тезис: достаточно мощная система типов гарантирует отсутствие ошибок
нет
0xd34df00d
13.01.2023 20:34+1А про агду из второго абзаца так же можно? Только с обоснованиями, если вы не против.
И с топами вашими из кулстори вы на самом деле так же обсуждали задачи?
vkni
13.01.2023 21:29Вам выдать чёрный пояс по фигурному цитированию? :-)
Там было «определённого класса». :-) Не надо зарываться в эти детали — ваша статья не об этом. Так вы только потратите время и разругаетесь с неплохими людьми.
ednersky Автор
13.01.2023 21:30-1я выделил место с ошибкой и процитировал, что не так?
не гарантирует. даже если в квоттинг вставить "определённого типа" - всё равно не гарантирует.
vkni
13.01.2023 21:33Всё не так — вы горячитесь, давайте вы сейчас вот это место заложите закладкой, а через неделю к нему вернётесь. Сейчас это просто трата времени.
DarthVictor
14.01.2023 14:09На этапе поддержки и крупного рефакторинга они и половину составлять могут.
nApoBo3
13.01.2023 10:20+6Вы предлагаете покрывать тестами всю возможную вариативность типов которые могу прилететь на вход?
12rbah
13.01.2023 12:13+1Вы предлагаете покрывать тестами всю возможную вариативность типов которые могу прилететь на вход?
Нет, я этого не предлагаю. Для иллюстрации того, что я говорю приведу пример, недавно на питоне я писал парсер и я использовал библиотеку для работы с url. В нескольких местах я ошибся и в функцию передавал не строку а объект этой библиотеки, самое плохое, что этот скрипт отрабатывал, а ошибка была найдена не сразу, например в c++ или go я бы физически не смог допустить такую ошибку, т.к. у меня проект не скомпилировался бы из-за того, что я использую объект вместо строки, а это был маленький скрипт на 300 строк, если будет проект на 5-10к то вероятность допустить ошибку будет гораздо выше. Поэтому для ряда функционала придется писать больше тестов или проверок в коде, ну или пойти путем дебага.
Andy_U
14.01.2023 00:18на питоне я писал парсер и я использовал библиотеку для работы с url. В нескольких местах я ошибся и в функцию передавал не строку а объект этой библиотеки,
Type hints + PyCharm + mypy (в strict mode) очень сильно уменьшают вероятность таких ошибок.
kasthack_phoenix
14.01.2023 09:01Type hints
Т.е. через переход к строгой статической типизации.
Andy_U
14.01.2023 09:09Т.е. через переход к строгой статической типизации
Для интерпретатора type hints - это комментарии...
kasthack_phoenix
15.01.2023 13:16+1Да, но я имею в виду, что люди пытаются имитировать статическую типизацию уровня компилятора прогоном линтера, что для наблюдателя особо не отличается.
TheGast
13.01.2023 12:08+3Зачастую это так. Как минимум, потому что тебе не нужен тест на то, что "результат вот этой функции -- действительно число". Тебе это прямо в сигнатуре функции дано.
Соответственно, остаётся проверять исключительно логику кода, а не его типы.
Ztare
13.01.2023 13:07В плане отношения к тестам - такого ввиду не имел. А вот невозможность IDE понимать тип, подсветить ошибку в имени метода (например) это прям боль - и понижает производительность моего труда. Накладные расходы на динамическую типизацию глобально неприятные. Поэтому динамические языки хороши для небольших продуктов и маленьких команд, для средних и крупных они вызывают проблемы.
ednersky Автор
13.01.2023 13:10В плане отношения к тестам - такого ввиду не имел. А вот невозможность
IDE понимать тип, подсветить ошибку в имени метода (например) это прям
боль - и понижает производительность моего труда.то есть вы подтверждаете тезис статьи, что мода на типизированные языки именно от того и растёт, что для них проще писать линтеры.
Cerberuser
13.01.2023 13:14+6Для них проще писать полезные программисту линтеры. То бишь, те, которые помогают ему, а не загоняют в рамки. Если таких не существует - ну, сочувствую.
Ztare
13.01.2023 14:25+2Проблема не в простоте написания линтеров - их написали уже умные дядьки. Проблема в том что в динамических языках чисто алгоритмически тип на месте может быть невыводим - насколько я знаю это сводится к проблеме останова. И второе - это цена выведения типа в динамических языках, тип по месту приходится вычислять с высоким потреблением памяти и процессора (и это фундаментальная не решаемая в общем случае насколько мне известно проблема), отсюда постоянно тормозящие IDE которые еще и тип не всегда выводят в конечном итоге.
Ivan22
13.01.2023 13:41+1А знаете почему JSON захватили мир? Это данные с нестрогой типизацией
12rbah
13.01.2023 14:57+8Ну да, только в rfc написано немного другое, где объект это name состоящее из строки и value, которое удовлетворяет одному из типов.
sshikov
15.01.2023 10:58+1Но в любой конкретный момент VALUE в одном и том же месте может быть как объектом, так и массивом. То есть тип одного конкретного элемента, с одним и тем же ключиком, будет разный сегодня и завтра. Или его вообще не будет. Но прямо сегодня он конечно имеет какой-то тип.
AnthonyMikh
15.01.2023 17:18Это никак не отменяет того факта, что всё многообразие JSON-значений можно описать одним типом.
12rbah
16.01.2023 08:09По сути все нестандартные типы в json переводятся в строку, отличие от питона ил js в том, что там когда видишь переменную, то ты не можешь быть уверен в типе, т.к. там объекты представляют собой именно отдельный объект, а не строку, в JSON когда смотришь на него, то всегда можно определить тип любого элемента, поэтому его не назовешь динамическим.
Shatun
13.01.2023 15:52+1Если бы JSON поддерживал стандартизованную схему в том же виде как xml то он бы стал значительно лучше и при этом это бы никому не мешало
ednersky Автор
13.01.2023 15:55-4Однако XML помер, а JSON нет
F0iL
13.01.2023 16:22+5Типизация здесь ни при чем. XML помер потому что он слишком многословный, плохо человекочитаемый и сложнее парсится.
sshikov
15.01.2023 10:31Мне каждое второе предложение работы приходит с упоминанием FIX протокола. Регулярно. Может в вашем мире розовых поней он и помер, а в моем мире кровавого энтерпрайза — цветет и пахнет. И кстати схема — это именно типизация.
Hlad
13.01.2023 12:30+1Забавно, что на ассемблере чуть ли не самой используемой командой является JMP (и её разновидности), которая, по сути, и есть GoTo...
F0iL
13.01.2023 13:22Потому что в ассемблере для безусловных и условных переходов кроме JMP и ее производных по сути дела ничего больше и нет?:)
Hlad
13.01.2023 13:27Почему же? CALL/RET ещё. И вот они как раз отлично подходят под требование "никаких GoTo".
F0iL
13.01.2023 13:52Делать условный if..else через CALL/RET - это как
заниматься сексом с чемоданомобязать всех разработчиков из if..else вызывать только отдельностоящие функции безо всяких там {}-блоков.О том и речь. В языках высокого уровня есть блоки кода: в языках с C-like синтаксисом это {..}, в Пайтоне уровень отступов, в Паскале begin..end.
В ассемблере всего нет, и поэтому переход к нужной части программы реализуется через JMP/JZ/JNZ. В каком-нибудь древнем диалекте Бейсика их тоже не было, поэтому там такое делали через GOTO, просто потому что по-другому никак.
DistortNeo
13.01.2023 13:25Поэтому требование по неиспользованию возведено в абсолют,
Ага. Вплоть до того, что есть ортодоксы, которые отрицают не только выход из вложенных циклов, но и исключения и
returnиз середины функции, ведь всё это ломает control flow.
panzerfaust
13.01.2023 09:38+17Боритесь! Отказывайтесь от вакансий, где вам предлагают работать над микросервисами.
Есть предложение еще и от денег отказываться. Желтый дьявол, презренный металл и далее по тексту. Брать продукцией! А при коммунизме все равно все бесплатно будет.
ednersky Автор
13.01.2023 09:43+3такое предложение будет неконструктивным (по крайней мере на данном этапе развития общества).
На деньги сейчас завязаны основные жизнеобеспечивающие функции.
а то что вы предлагаете сродни следующему: "Если goto иногда полезен, то давайте применять goto абсолютно в каждой строке. Получится фигня, сами можете убедиться".
Но нет, истинный пролетарий на подобную уловку не поддастся!
NNikolay
13.01.2023 11:50+4Вам нужно профсоюз организовать. И провести стачку "против микросервисов" - все технологии уже сто лет назад апробированы.
А если серьёзно, то нужно ребрендинг сделать монолитам и внедрять как новинку.
ednersky Автор
13.01.2023 12:23+1Вам нужно профсоюз организовать
профсоюзы - буржуазный метод перенаправления революционной энергии пролетариата... в свисток.
об этом ещё товарищ Ленин писал.
NNikolay
13.01.2023 13:32Эх, всегда так в России. Только революция и никаких переговоров.
Я, кстати, сильно удивился, что среди кучи аргументов Ваш "босс" ни разу не проговорился о правде в этой шутке. Чем больше микросервисов, тем больше нужно разработчиков, тем круче их начальник. Вот это правда как она есть. Как "босс" говорю.
ednersky Автор
13.01.2023 13:57-2Эх, всегда так в России
а почему "Эх"?
Это не хорошо и не плохо, это просто менталитет у нас такой. У немцев, например, другой, у французов -- третий.
Просто модель поведения, выбранная нашими предками.
1755
13.01.2023 20:35Нет никакого такого менталитета, если какие-то привычки и системы, в которых мы живём. Или Вы хотите сказать, что в России у русских, украинцев, татар, башкир, черкессов, бурят, тувинцев и еще у десятка проживающих в России национальностей одинаковый менталитет?
event1
13.01.2023 18:38А если серьёзно, то нужно ребрендинг сделать монолитам и внедрять как новинку.
Это гениально по-моему. На уровне SSR веб-приложений. Предлагаю IMC (In-Memory Communication) микросервисы.
xenon
14.01.2023 00:14+1Есть интересная тема - JAMstack (Javascript/API/Markup). Это "новые статическе сайты". Они прекрасны - их можно хостить на CDN, быстро загружаются, их любит гугл, они приятны пользователям (не тупят) и за счет JavaScript они абсолютно функциональны. Ну и достаточно сложно взломать сайт из набора HTMLок (в отличие от такого же сайта-визитки на вордпрессе).
Но эта технология (в каком-то смысле возврат к ~90-ым годам) сейчас модная потому, что второй раз заходят в уже другую реку. Сейчас есть очень мощный JavaScript и поэтому сайт может быть "живым". В 90-ые, если у тебя сайт бы не на PHP/Perl - он был "мертвым".
Вот если бы была какая-то технология, которая ты как-то делала монолиты не такими как раньше - это было бы интересно.
12rbah
13.01.2023 09:42+9Что такое микросервис, значительная часть которого кодогенерируется? Это способ изолировать разработчика от целого (и друг от друга). Это
жёсткий контракт в YAML-файлах: "На входе требуется вот это, а на выходе вот то, приступай!".На самом деле это обычный подход для написания крупных систем, разве что только форма меняется. Об этом еще брукс писал в мифическом человеко-месяце, при большой системе нет особого выбора кроме как разделять всё на части и прописывать интерфейсы для взаимодействия между этими частями(интерфейсы не в прямом смысле для программирования а просто как точка взаимодействия). Суть в том что почти никто не может написать большую систему самостоятельно, можно написать например базовую версию ядра ОС, какие-то библиотеки, но если проекту нужно активное развитие то придется нанимать больше разработчиков, которые будут тратить время менее эффективно, т.к. со временем большая часть времени начнет уходить на взаимодействие, но время написания проекта сократится.
И всё бы ничего, но только он толкнул в массы новую "мегаидею" (по аналогии с "
goto— это плохо"): "Исключения — это плохо!"Ну на самом деле суть не в этом, если нужно обертнуть код исключениями то это можно сделать, например если вызвать панику в обработчике http сервера, то приложение не упадёт и продолжит работать. Основная идея в том, что нужно стараться осознанно обрабатывать ошибки и писать код который предотвращает эти ошибки, почему-то в голову приходит пример с калькулятором, почему везде где показывают пример, деление на 0 записывают в исключительные ситуации, вместо того, чтобы в функции просто сделать проверку на 0 и вернуть ошибку. Кода из-за этого на самом деле получается больше, но по моему личному опыту среднее качество и средняя надежность выше, а время на обнаружение ошибок и отладку меньше.
Вот пример кода отсюда https://learn.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-170, но вот лично я не очень уверен, что программа должна падать из-за такого, если человек забыл например обработать исключение. Раздел называется "Modern C++ best practices for exceptions and error handling". Я на плюсах писал мало, поэтому буду рад, если кто-то подскажет нормально ли так делать? Просто не очень хочется каждый раз лезть в документацию или код и смотреть в каких случаях лкасс кидает исключение.
#include <stdexcept> #include <limits> #include <iostream> using namespace std; void MyFunc(int c) { if (c > numeric_limits< char> ::max()) throw invalid_argument("MyFunc argument too large."); //... } int main() { try { MyFunc(256); //cause an exception to throw } catch (invalid_argument& e) { cerr << e.what() << endl; return -1; } //... return 0; }Боритесь! Отказывайтесь от вакансий, где вам предлагают работать над микросервисами. Встречно предлагайте монолитные приложения!
Удалите из своего IDE форматирующие код расширения, уничтожьте линтеры, верифицирующие стиль, оставьте только те, что дают информацию о возможных ошибках. Заставьте творца, который живёт внутри, выйти на первый план!
Честно говоря похоже на троллинг.
Надеюсь, эта статья поможет читателю выбрать правильную сторону в этой
вечной борьбе сил света и тьмы. К счастью, или, увы, но отсидеться в
сторонке не получится.Да спасибо. А теперь пойду перекладывать json-ы между своими микросервисами
ednersky Автор
13.01.2023 09:45Основная идея в том, что нужно стараться осознанно обрабатывать ошибки
и потому возьмём кнут и заставим разработчиков стараться. Иных мер убеждения нет.
Просто бизнес, ничего личного12rbah
13.01.2023 09:59+2и потому возьмём кнут и заставим разработчиков стараться.Иных мер убеждения нет.
Ну для большинства го - это не первый язык, никто не заставлял их учить его и писать на нём. Очень много людей переходят на него после плюсов и довольны этим языком(это личный опыт и знакомства, поэтому как у других я не знаю). Да и в целом никто не заставляет писать обработку ошибок просто в реальности на написание этой логики тратится мб процентов 10-15 времени, но за счет этого почти всегда получаешь точное место ошибки и хотя бы примерное описание того и что произошло.
К сожалению, видел довольно много кода, где либо люди забивают на обработку ошибок, либо заворачивают большой кусок кода в try и пишут один catch(...) который обрабатывает все ошибки и пишет сообщение по типу "произошла ошибка". Не знаю насколько это законно в продакшен коде.
В могу сказать, что го подходит не всем у языка есть свои + и -, своя идеология и свой стиль написания кода, мне тоже не нравится ряд языков, но это нормально, если язык занимает свою нишу значит имеет определенные достоинства, за которые его выбирают.
ednersky Автор
13.01.2023 10:00+1Ну для большинства го - это не первый язык, никто не заставлял их учить его и писать на нём
рыночные меры убеждения заставляли.
- Хочешь работать в транснациональной корпорации?- да- учи Go
ednersky Автор
13.01.2023 10:02+1либо заворачивают большой кусок кода в try и пишут один catch(...)
который обрабатывает все ошибки и пишет сообщение по типу "произошла
ошибка". Не знаю насколько это законно в продакшен коде.по мне так это - идеальный паттерн
стек ошибки отправляется в хранилище, откуда разработчик может достать, разобраться и поправить.
вы не видели на сайтах: "случилось что-то непредвиденное, мы уже разбираемся"? это вот оно и есть12rbah
13.01.2023 10:13"случилось что-то непредвиденное, мы уже разбираемся"
Для фронтэнда да идеально, пользователю не нужно знать что именно произошло, а условну разрабу разгребать стектрейс, а не конкретную ошибку не очень понравится.
Хочешь работать в транснациональной корпорации?Помимо го нужно еще выучить язык, решить много задач на leetcode, получить визу, подготовиться к собеседованию, да и есть куча вакансий где пишут на питоне, ноде, яве, го не настолько популярен как вы представляете это в комментарии, да и в жизни бывает такое, что приходится делать что не нравится
ednersky Автор
13.01.2023 10:15Для фронтэнда да идеально
насколько знаю, большинство таких ошибок рождено именно микросервисным бакендом (и потому рефреш помогает)
RH215
13.01.2023 15:33и потому возьмём кнут и заставим разработчиков стараться.
То есть мы по умолчанию считаем разработчика ленивым и халатным?
ednersky Автор
13.01.2023 15:36я о той ситуации что есть: обязать разработчка в каждой первой функции писать обработку ошибок, то есть делать работу за компилятор, иначе как "кнутом" я назвать не могу
ну совсем ведь не пряник
RH215
13.01.2023 15:46Ну тут проблема больше в том, что в Go исключения убрали, а придумать другой метод прокидывания ошибок - забыли. Но там в целом язык странный.
А сама по себе возможность знать, что данная функция может вернуть такой-то класс ошибок - замечательна.
nApoBo3
13.01.2023 09:50+23Приходишь потом за такими вот творцами и понимаешь, проще все сравнять с землёй , чем реанимировать. Макароны плотно оплетающие велосипеды. И главное эту люди потом гордятся, я один все наваял, а после моего ухода целый отдел набрали. И не вдомек им, что необходимость в целом отделе, это последствие их творческих порывов. Бегут они по жизни дальше несомые творческим шилом в пятой точке оставляя за собой макаронные джунгли, а кому то потом все это разгребать и поддерживать.
ednersky Автор
13.01.2023 09:55+1есть анекдот про переписывание кода. он матерный потому приводить здесь не буду
краткое содержание: заказчик жалуется, что каждый новый нанимаемый им программист называет предшественников нецензурно и начинает переписывать.
вместо сравнивания с землёй может лучше попытаться разобраться? Не?
auresio
13.01.2023 10:12+1В вашем утверждении логическая ошибка, если творец низкоквалифицирован, то как получилось что на его замену нужна целая команда проффесионалов? Может наоборот, вместо одного спеца набрали кучу студентов которые каждый в своей стезе что то понимает и этот змей горыныч кое как тянет то что раньше делал один человек? Или просто бизнес вырос из решения которое предлагал один человек и настала пора масштабироваться.
P.S. Чем квалифицированнее разрабочик тем он сдержанее относительно оценки труда предшественников и тем реже от него можно услышать предложение "а давайте все перепишем на {itemname}". Ничего личного, просто собственный опыт и наблюдения.RH215
13.01.2023 15:37+4то как получилось что на его замену нужна целая команда проффесионалов?
А тут может быть разница между решением работающим как-нибудь и решением, работающим хорошо , стабильно и в рамках строгих метрик.
nApoBo3
13.01.2023 16:41+4Нет в моем утверждении логической ошибки.
Человек лепит свою нетленку. Сначала он выкатывает "фичи" достаточно бодро, становится часть коллектива, герой на коне, помог всем и вообще "сын маминой подруги". Потом фичи появляются все реже, но люди привыкают, он же герой. Потом система начинает терять стабильность и наш герой героически ее чинит, и в выходные, и ночью, и в отпуске , бухгалтерия в отчётный период носит его на руках он опять всех спас, а про новые фичи все давно забыли, в этот момент герой уже неотделимая часть механизма.
И в какой-то момент герой расправляет плечи и летит лепить новую нетленку. И вот тут и выясняется, что не зря он по ночам работал, а новые люди о чудо не хотят этого делать, разгребать чужие косяки ценой своего сна, и действительно сложно поместить в голову то нагромождение костылей которые были заботливо везде расставлены, и кнопочку два года в красный он не просто так не мог перекрасить, а потому, что проект валиться совсем при таком изменении в самых неожиданных местах.
И да, я не призываю ничего переписывать с нуля. Просто нужно понимать, что рефакторить нетленку, дороже и дольше чем написать с нуля, но чаще всего применяется именно глубоки рефакторинг, поскольку остановить бизнес на пару лет это не очень вариант, да и результат не гарантирован.
auresio
13.01.2023 17:15Вы знаете вот опять таки субьективно и из личного опыта, команды никак не защищены от подобного..Я лично рефакторил/переписывал проект целыми модулями за командой лепил, больше года..привел в состояние "оно работает и не падает от ветра" и я вам так скажу, парни работали по правилам и бест практикс, настолько что мне это слово уже приелось. Потом правда бест практикс оказались макоронным кодом который писали 2 года до меня.
Так что я не знаю какого именно сферического коня в вакууме вы тут описываете, но помоему важно не количество разработчиков, а качество. Потому что "псих одиночка" которого вы тут описали может быть действительно результативным. Я знаю потому что в моей работе такой был, правда он ничего не спасал, у него все было вылизано за большое количество лет и работало как надо. Мой ему низкий поклон, очень умный дядька, занимался разработкой архитектур процессоров в 90-х.
kasyachitche
13.01.2023 09:50+1Вы не против подискутировать по сути, но по какому тезису? Который вынесен в заголовок? Или по тезису типа: "в it происходит "первая промышленная революция"?
ednersky Автор
13.01.2023 09:56+2Вы не против подискутировать по сути, но по какому тезису? Который вынесен в заголовок?
именно
Или по тезису типа: "в it происходит "первая промышленная революция"?
промышленной революции в IT не происходит. IT не развивается (интенсивно) уже более полусотни лет (в списке литературы есть статья на эту тему, кстати)
kasyachitche
13.01.2023 10:13Жаль, что ни разу к микросервисам не прикасался.
А вот про отсутствие развития в it согласиться не могу. И статья в источниках никак тезис об отсутствии развития не подтверждает. Здесь и всегда, конечно же, ИМХО.
Еще забавно, что прочитав вашу статью, я резюмировал ее в тезис про революцию, с которым вы не согласны))
ednersky Автор
13.01.2023 10:20+2А вот про отсутствие развития в it согласиться не могу
в комментарии было слово "интенсивно"
простое заполнение пустого пространства - не есть интенсивное развитие.
в школе учили:если крестьянин засеивает всё больше и больше новых полей - это экстенсив (то что есть в IT)
если он увеличивает урожайность (разрабатывая новые способы итп) - это интенсив
что есть в IT?
новые технологии? какие? асинхронность? была 50 лет назад, сейчас её просто стало больше
может быть нейронные сети? и им тоже более 50 лет. просто люди вручную насобирали базы данных и стало возможным эту информацию через нейронки пропускать. Не более того. ничего нового в них не. чистое экстенсивное развитие.
может новая парадигма появилась? аналогичная ООП? снова нет. и даже типажи на это не тянут.
kasyachitche
13.01.2023 10:47+9Асинхронность и прочие базовые вещи (в том числе и парадигмы) - это как алгебра в современной математике. Простая основа, кирпич из которого можно строить замки. Я не могу принять этот довод как показатель отсутствия интенсивного развития. Для меня это не очевидно. Сможете ли вы привести аргументы в пользу того, почему базовые концепции должны быть заменены при интенсивном развитии? Например, почему в будущем мы должны отказаться от асинхронного программирования или от использования классов?
То, что нейронные сети были изобретены 50-70 лет назад - не показатель того, что с тех пор не было интенсивного развития. Посмотрите на количество публикаций по темам, связанным с ИИ и с нейронными сетями. Последние годы виден невероятный рост отрасли и проникновение технологий, связанных с AI, во все сферы жизни и промышленности. Как ни крути, но такой рост (скорее экстенсивный) приводит к качественному изменению этой технологии, то есть к росту интенсивному. Если раньше (20 лет назад), нейронные сети могли распознать рукописную букву, то сейчас вы можете попросить ее переписать текст, поуправлять авто или технологическими процессами, придумать вам историю или анекдот, поговорить с ней, написать картину, да даже код за вас написать, то есть формально нейронные сети могут самовоспроизводиться (не принимайте этот аргумент как совершенно истинный, он возможный))) и т.д. и т.п. Это качественное изменение, то есть интенсивный рост отрасли. Я не понимаю, почему такой рост в статье по ссылке называют экстенсивным. Экстенсивно - это когда ты преумножаешь существующее, а когда тебе приходится изобретать новые технологии, чтобы обуздать возрастающие объемы, - это и есть интенсивное развитие.
Если переходить к более привычному программированию, то резюмируя вашу статью, я, как человек не знающий что такое микросервисы, понял их как элемент интенсивного развития, как новую технологию, направленную на то, чтобы создавать огромные программные системы, которые могут обслуживаться тысячами неуникальных работников, дописываться, изменяться, развиваться на лету, которые не могут существовать в рамках тех технологий, которые были 20 лет назад. Раскрывая тезис: экстенсивный рост сложности программ привел к появлению этой технологии (качественному росту, интенсивному развитию всей отрасли), чтобы экстенсивное развитие могло происходить дальше.
Переходя к аналогиям с крестьянами: в какой-то момент вспахать одной лошадью землю уже не получится, придется изобретать трактора, переходить к разным сортам злаков, имеющих разбег во времени посева, придумывать способы хранения, транспортировки и обработки зерна в больших объемах. Раньше для всего хватало одного крестьянина с лошадью (программист и Pascal), а теперь нужно городить огромные системы (бэк, фронт, DA, DS, DE, DevOps, и т.д. и т.п.), и в разных частях систем будут разные технологии (пусть и построенные с использованием базовых примитивов). И именно в этом есть интенсивное развитие.
ednersky Автор
13.01.2023 12:25Асинхронность и прочие базовые вещи (в том числе и парадигмы) - это как
алгебра в современной математике. Простая основа, кирпич из которого
можно строить замки. Я не могу принять этот довод как показатель
отсутствия интенсивного развития.Интенсивность развития предполагает на замену кирпичных зданий принести железобетон.
а массовое кирпичное строительство - это просто заполнение ниши - чистой формы экстенсив
kasyachitche
13.01.2023 13:14+1Речь не о строительстве все-таки, а о том, что есть базовые концепции на которых все строится. Почему для вас интенсивное развитие невозможно без их замены?
ednersky Автор
13.01.2023 13:21Речь не о строительстве все-таки
я пытаюсь аналогиями донести различие "экстенсивное развитие" vs "интенсивное"
PS: Помимо прочего, есть такое понятие (марксистское кстати), как "Переход количества в новое качество".Да, если экстенсива будет много-много-много, то это даст новое качество (или не даст), о котором можно будет подискутировать: это интенсив или экстенсив.
Да, повсеместное применение нейронок неизбежно приводит нас к новому качеству. Тут я бы и спорить не стал. Другой вопрос, что нейронкам полвека и за эти пол века в них ну почти ничего не поменялось (это чистый экстенсив)kasyachitche
13.01.2023 13:31Давайте про нейронки в другую ветку ниже, а здесь только про базовые концепции.
Аналогии лишь для красоты и уточнения)) Если я правильно понял, то для вас один из признаков отсутствия интенсивного развития - это, например, повсеместное применение асинхронного программирования. Почему?
ednersky Автор
13.01.2023 13:43Если я правильно понял, то для вас один из признаков отсутствия
интенсивного развития - это, например, повсеместное применение
асинхронного программирования. Почему?если снова принести аналогию с крестьянами (они правда для красоты и уточнения)
Так вот, жил-был крестьянин и было у него три поля.
На одном он всегда сажал пшеницу, на втором - картошку, на третьем - помидоры.
Однажды сосед ему и говорит: чудак человек, чередуй ежегодно что где растёт и твоя урожайность повысится.
Но крестьянину было пофиг. Он не хотел развивать свой хозяйство интенсивно.
Затем прошло время и бОльшие урожаи всё-таки ему потребовались: ценники на рынке упали, барщину подняли и он таки перешёл к новому виду хозяйствования.
Является ли этот шаг интенсивным развитием? С одной стороны вроде бы да. Но запаздывая за другими на полвека, кажется, что уже и нет.
вот какое-то такое у меня отношение к асинхронному программингу.
kasyachitche
13.01.2023 14:16Я не могу соотнести ваш пример с асинхронным программированием. Вы хотите сказать, что уже сейчас должно прийти что-то новое, но запаздывает по сравнению с развитием чего-то другого (может железа?), и это что-то заменит асинхронное программирование? И только тогда будет интенсивное развитие?
ednersky Автор
13.01.2023 12:29+1То, что нейронные сети были изобретены 50-70 лет назад - не показатель
того, что с тех пор не было интенсивного развития. Посмотрите на
количество публикаций по темам, связанным с ИИ и с нейронными сетями.
Последние годы виден невероятный рост отрасли и проникновение
технологий, связанных с AI, во все сферы жизни и промышленности.50-70 лет назад чего не хватало для проникновения этих технологий во все сферы жизни? Двух вещей:
вычислительной мощности (это не про IT, по крайней мере не про софтверное IT)
количества материала для обучения. то есть вручную составленных 100500 баз данных измерений.
то есть если говорить, что нейронки - это революция (интенсив) то произошла она 50+ лет назад, а теперь мы пожинаем её плоды.
как-то так.
kasyachitche
13.01.2023 13:24+1Давайте посмотрим на этот вопрос по другому. Перцептрон Розеблата (речь про него, как я понимаю) - это просто функция от линейной композиции нескольких переменных. С этим работал еще Ньютон (но что-то мне подсказывает, что началось все задолго до него). Получается нейронные сети были изобретены несколько веков назад? Из эти века мы всего лишь научились использовать много функций, благодаря которым можем работать с большим количеством информации, то есть это было простое экстенсивное развитие? А ChatGPT - просто огромная функция (экстенсивно развитая), а не нечто большее?
Ну и слегка подкину на вентилятор: а что такое человек? Экстенсивно развитый многоклеточный организм с существенным увеличением количества клеток? Или в какой-то момент произошел интенсивный процесс развития, хоть состав клеток особо то и не изменился?
Kwent
13.01.2023 18:50+6Ну нет, это слишком сильное упрощение, так можно сказать что нейросети не развивались тысячи лет, ведь сложение, умножение, вычитание и деление существуют давно.
Буду ссылаться на метафору строительства
Я бы сказал что в нейросетях с персептрона Розенблатта было как минимум несколько действительно революционных шагов, за уши их можно назвать эволюционными, но все-таки я считаю их именно революционными:
1. 80-90ые, сверточные слои для обработки изображений, рекуррентные слои для обработки текста и последовательностей. Это именно смена кирпича на железобетон, то есть мы меняем строительный материал с полносвязного слоя на слой сверточный или рекуррентный. Если свертка существует давно как оператор обработки сигналов, то здесь она все-таки используется по-другому. Необходимо было разработать неплохой мат аппарат для этого, а еще и поверить что это вообще рабочая история. Там несколько раз нагло закрыли глаза на ограничения математики и перешли скорее к практическим приближенным вычислениям в ущерб тому, что математически не очень работает. Пример - функция активации ReLU (=0 if x <= 0 and =x if x>0), которая не дифференцируема в 0, но все работает. Тут важный момент становления "науки нейросетей", если раньше было "придумаем аналитически математикой, потом будем обучать", то сейчас "сделаем что-то, что хорошо работает, потом математикой попробуем объяснить как это работает". Это не конкретно про ReLU, просто остальное сильно сложнее для примера, но таких "хаков" сейчас уже десятки-сотни.
2. 2010ые, глубокие сети, лидерство нейросетей в распознавании изображений. Кажется, что это чистой воды эволюция, но нет, некоторые время глубокие сети не считались чем-то адекватным из-за 1) проблем обучения 2) теоретически три полносвязных слоя могут выучить вообще все (это, емнип, даже математически доказано). Поэтому объединить много слоев и заставить это работать -- именно что революция (ей и стало по духу). Это как начать строить многоэтажные дома из тех же материалов, тут нужен особый подход и технологии.
3. Наше время -- огромные сети на архитектуре трансформеров, которая тоже вполне себе революционная, общего у трансформера и исходного персептрона, как у шалаша и небоскреба, тоже дом, но есть нюанс. Уже и материалы и технологии строительства другие.0xd34df00d
13.01.2023 19:29+1это, емнип, даже математически доказано
Да, теорема Колмогорова. Правда, ЕМНИП про гладкие функции, но на практике у нас все гладкое в мире.
kasyachitche
13.01.2023 21:15Вот именно, что перцептрон и нынешние сети - вещи разные. Полностью согласен с вами.
AlexeyK77
13.01.2023 15:40+120-30 лет назад были уже все виды сетей, но не было: доступных БД с данными для обучения, и навреное главное - не было достаточных вычислительных мощностей. В середине 90х будучи еще школьником старших классов увлекся этой темой, когда про нее особо и не слышали. Обучать слабенький персептрон на 486й машине можно было только из большой любви к науке, практической пользы не проглядывалось.
А вот что конечно явно изменилось, так это подход к обучению НС, как залог успешности результата, вот тут можно зачесть прорыв.DistortNeo
13.01.2023 21:00+220-30 лет назад были уже все виды сетей, но не было ...
А ещё не были разработаны эффективные алгоритмы для оптимизации коэффициентов нейросетей. Алгоритм Adam — это 2014 год. До него все использовали SGD (и хорошо, если с моментами), с которым и с нынешними мощностями мало чего можно добиться.
Также не было понимания, что решают именно глубокие (многослойные) нейросети. Многим эта идея казалась бесперспективной, из-за чего не удавалось достичь с помощью нейросетей результатов приемлемого качества.
0xd34df00d
13.01.2023 19:26+1может новая парадигма появилась? аналогичная ООП? снова нет. и даже типажи на это не тянут.
Монадки завезли, линейные (и прочие) типы, и так далее.
А типажи на самом деле строго выразительнее ООПных интерфейсов, так что зря вы так.
ednersky Автор
13.01.2023 20:09-5монады - такая же колбечная лапша, просто вид сбоку.
мало того, взяли очевидное, доступное во многих языках, и назвали модным (монадным) словом...
мда0xd34df00d
13.01.2023 20:36+1монады — такая же колбечная лапша, просто вид сбоку.
Какая колбечная лапша? Где вы увидели коллбеки в List/Maybe/State/etc?
мало того, взяли очевидное, доступное во многих языках, и назвали модным (монадным) словом...
То, что доступно в других языках, в подавляющем большинстве случаев является синтаксическим сахаром для каких-то частных случаев (ну там,
?в расте,awaitв JS/C#/etc).ednersky Автор
13.01.2023 20:39-2Какая колбечная лапша? Где вы увидели коллбеки в List/Maybe/State/etc?
колбечный (иногда асинхронный) код можно оптимизировать по разному. Промисы, монады итп. Потом кто-то неизбежно приходит и говорит "ну что за гадость?" и схлопывает это в файберы/корутины, позволяющие писать нормально, без колбеков.
берём объект каждый метод которого возвращает self и пишемfoo.bar().baz()чем не монада? ах возвращаемое значение нужно? ну дык добавьте его. это что, прорыв? да ну нафиг
0xd34df00d
13.01.2023 20:42+12Я очень не люблю сводить спор к перекидыванию такими аргументами, но, мам, он первый начал, так что просто скажу: вы нихрена не разбираетесь в теме, и ваш ответ не имеет вообще никакого отношения к вопросу. Смутные подозрения от уравнивания методов обработки ошибок в го и в расте превратились в совсем не смутную уверенность.
ednersky Автор
13.01.2023 20:43-4дык и я вам постоянно это же говорю.
смиритесь, но вы - балабол
0xd34df00d
13.01.2023 20:48+6Я у вас спросил, где вы в самой концепции монады увидели коллбеки, вы мне вместо этого начали писать про использование коллбечного кода (который не обязан быть монадическим) и про то, как люди пишут вещи без монадических абстракций. Потом вы приводите какой-то код на питоне и спрашиваете, чем это не монада — ээ, всем? Чем это монада?
Я не понимаю, что при этом у вас происходит в голове и как вы вообще прожили по вашим же словам больше четверти века, не отфильтровывая автоматически такой бред.
ednersky Автор
13.01.2023 20:57-1что такое функциональное программирование?
это программирование, при котором разработчик описывает что происходит (функции), а не манипуляции с данными.
в общем виде функциональный код:
foo(bar(baz(data0)))
императивно этот же код можно переписатьlet r = baz(data0)
let r = bar(r)
и так далее
вот эти bar, baz - колбеки/функции/хоть пирожком назови.
монады - это способ попытаться остаться в парадигме функционального программирования, но так, чтобы было похоже на императивное.
таких способов много: промисы, всегда возвращаемый self во всех методах, монады, и прочие map-reduce.
Только речь идёт о том, что раз вам так хочется писать псевдоимперативно, то пишите императивно! Это будет эффективнее.
Нет? не мучайте функциональный язык
0xd34df00d
13.01.2023 21:12+1Как я и писал, у вас полное непонимание.
Типа, когда я пишу на идрисе
myShit data0 = foo (bar (baz data0))то это ФП, а когда я переписываю это в полностью эквивалентный
myShit data0 = let r = baz data0 in let r = bar r in let r = foo r in rто у меня тут резко начинается императивное программирование?
что такое функциональное программирование?
это программирование, при котором разработчик описывает что происходит (функции), а не манипуляции с данными.Это если вы застряли в 70-х. Тогда манипуляции функциями, функции как сущности первого класса, и так далее, были чем-то новым. Сейчас это есть в практически всех мейнстримных языках, и основной критерий ФП — это контроль в типах над эффектами ваших функций.
монады — это способ попытаться остаться в парадигме функционального программирования, но так, чтобы было похоже на императивное.
А когда я пишу что-то в монаде
Maybe, или пишу парсер на монадах, где тут императивное программирование?parseDecl :: Parser Declaration parseDecl = do ty <- parseTypeRef <* spaces varName <- parseName <* spaces void $ string "=" <* spaces initExpr <- parseExpression pure $ Declaration ty varName initExprГде здесь колбечная лапша и императивное программирование?
и прочие map-reduce.
Лолшто.
Это будет эффективнее.
Не будет.
ednersky Автор
13.01.2023 21:16-4Как я и писал, у вас полное непонимание
как я и писал выше, у вас полное непонимание.
неспособность за частностью увидеть целое. Упёрлись в свой идрис и приводите совершенно никчёмные примеры, совершенно не в тему.
ну хорошо хоть идрис выучить удалось, осталось научиться писать на нём полезный код.
понимаю, задача не про вас, но попробуйте поставить такую цель
ednersky Автор
13.01.2023 21:21-5на ваши - нет
притчу о вопросах, на которые не могут ответить 100 мудрецов помните?
как раз ваш случай
0xd34df00d
13.01.2023 21:24+9Ваш тезис: монады — колбечная лапша.
Я привёл пример монадического кода и спросил, где там колбечная лапша.
Ваш ответ: никчёмные примеры, не в тему, частности.Не понимаю, зачем высказывать срывающее покровы мнение, а потом отказываться его как-то обсуждать и обосновывать. У нас и так глобальное потепление, нет нужды усиливать парниковый эффект настолько бурной газификацией луж.
ednersky Автор
13.01.2023 21:27-1Ваш тезис: монады — колбечная лапша.
нет, видите, вы даже прочитать не можете внятно
монады - такая же колбечная лапша, вид сбоку
монады - просто одно из средств борьбы с колбечным адом: промисы, мап-редюсы, конвееры из точек, монады - всё одного поля ягоды.
Впрочем я обещал с вами не спорить, поэтому это мой последний коммент к вам.
0xd34df00d
13.01.2023 21:30+2Ясно, очень важное уточнение, ни в коем случае не частности. Не то, что мои какие-то тупые примеры.
Про императивное программирование с парсером выше и спрашивать не стоит, видимо.
capgelka
14.01.2023 06:37Вы вообще спорите о разном. Вмешиваюсь, потому что статья как нечто глобальное понравилась, но с некоторыми примерами вы были не слишком точны, но зачем-то их защищаете, хотя фактически в тексте обещали таким не заниматься.
А к оппоненту, как где-то выше упомянули имеете личную неприязнь, поэтому не сдерживатесь и пытаетесь спорить, выставляя себя местами не в лучшем свете.
Все это плохо влияет на восприятие статьи, так как сильно подрывает образ «матерого деда, который комитил в ядро еще когда не все читатели свой первый hello world написали''.
Поскольку вы в целом воспринимаете оппонента очень предвзято, и также относитесь к его аргументации (а в данном случае опровергать чужой тезис пришли именно вы), я попытаюсь максимально объективно выдать содержимое этого треда, чтобы вы могли также непредвзято взглянуть
Тезис (локально) противоположной стороны, что монады это не только способ работы с асинхронными вычислениями, но и множество других применений (в которых никаких колбеков нет).
Вопрос о том насколько они удобны/нужны при этом остается за скобками. При том что в мейнстримных языках монад как явной сущности нет, есть просто вручную встроенный набор монадических методов в стандартные контейнеры.
Ваш тезис, что в асинхронном программировании монады это те же колбеки под капотом, и проблемы не решают.
С ним можно соглашаться, а можно спорить, но ваш оппонент говорит вообще о другом, защищая свой тезис и монады в целом.
Если вернуться к началу ветки, то в данном случае, изначально вопрос был поставлен про инновационность монад как примера интенсивного развития, и попытка ее опровергнуть на основе того что конкретное хорошо известное вам применение в асинхронном программировании не иновационно кажется не очень корректным.
А так вот на хабре же есть отличная статья habr.com/ru/post/429530 с очень конкретным и выразительным примером никак с асинхронностью не связанным.
Субъективно кажется, что монады и сопутствующий аппарат современного (вообще уже не столь, просто до мейнстрима долго идет, ну и каких-то фреймворках и библиотеках мощных построенных на данном подходе) функционального программирования это как собственно приход структурного программирования на смену goto (что не значит, что у него не остается области применения), но если вы не считаете и случившееся тогда инновационным, то логично что тут тоже ничего такого нет, просто куча сахара.
ednersky Автор
14.01.2023 07:46-1а в данном случае опровергать чужой тезис пришли именно вы
а у него не было тезисов. он пришёл и как всегда назвал всё демагогией и полез со своими монадами.
при том как всегда сам не понимает что такое монада вообще (правда вот выше, вроде наконец до него дошло, что промис — частный случай монады, осталось сделать ещё один шаг к ненужности и промисов и монад, который сделали даже в питоне)
ednersky Автор
14.01.2023 07:54-2Тезис (локально) противоположной стороны, что монады это не только способ работы с асинхронными вычислениями, но и множество других применений (в которых никаких колбеков нет).
попробуйте монады написать на другом языке, например на чистом JS. Получится у вас это без колбеков (или методов класса, кои тоже колбеками являются)?
если один язык, интересный чуть менее чем никому, нарисовал про монады безколбечный синтаксис, это не отменяет колбеки.
ровно так же как если другой язык нарисовал про промисы безколбечный синтаксис — это не отменяет, а просто прячет под капот те самые промисы
как-то так
0xd34df00d
14.01.2023 08:12В вашей формулировке и композиция функций — коллбеки. И, кстати, поэтому композиция функций — ненужный коллбечный ад, потому что коллбеки нужны только для промисов, а после того, как мы промисы заменили на async/await, коллбеки стали не нужны. Нужна ли после этого программисту композиция функций? Ответ: не нужна.
ednersky Автор
14.01.2023 08:13как обычно — каша в голове. сходи проспись. я даже не смог распарсить тот мусор что ты сюда вывалил
0xd34df00d
14.01.2023 08:16+4Ну вот обычно — ты в очередной раз не понял, что пишут окружающие.
Что у тебя каша в голове, впрочем, не новость.
0xd34df00d
14.01.2023 08:20Ну и да, для протокола — это прямая пародия на ваш «аргумент» про async/await в питоне и монады чуть выше. То, что вы её не смогли распарсить — это, ну, это довольно печально. Что ж.
ednersky Автор
14.01.2023 08:24если не создавать себе трудности, которые потом придётся героически преодолевать, то монады не нужны.
собственно статья именно об этом: приходит поветрие, делает всем плохо, затем приходят умники с монадами и говорят "это панацея". Если бы ранее не пришли умники с хейтом того или иного подхода (динамические типы, goto, KISS, итп) то и эта впариваемая "панацея" тоже нафиг бы никому не нужна была
0xd34df00d
14.01.2023 08:26Да, пришло поветрие, сделало вдруг парсерам на стейтмашинах плохо, создало проблемы, а потом героически их преодолело. Да, всё так и было.
Лан, надо это действительно сворачивать.
Про панацею, кстати, никто не говорил.
ednersky Автор
14.01.2023 08:28Да, пришло поветрие, сделало вдруг парсерам на стейтмашинах плохо, создало проблемы, а потом героически их преодолело. Да, всё так и было.
но общая сложность осталась высокой, KISS-принцип нарушен.
Про панацею, кстати, никто не говорил.
я с тобой спорю уже лет пять. и всегда ты эти монады пихаешь. я хз. у тебя видимо процент от их продаж там в доходе?
Cerberuser
14.01.2023 09:41Где вы увидели коллбеки в List/Maybe/State/etc?
Рискну предположить, что с точки зрения автора статьи любой интерфейс, принимающий функции, в частности, любой continuation-passing - это "колбечная лапша". В том числе и монадический
bind.0xd34df00d
14.01.2023 19:59У меня тоже была такая гипотеза, поэтому я там рядом вбросил аналогичный тезис про композицию функций — автору не понравилось. Значит, эту гипотезу отметаем.
CodeRush
13.01.2023 10:04+45Призыв изучать все подряд поддержу, все остальное - точно нет.
Дело в том, что ваше "творчество" именно что никому в бизнесе не нужно, там нужен предсказуемый результат к предсказуемым же срокам. Хотите творить - творите у себя дома, выкладывайте в открытый доступ (или не выкладывайте, дело ваше), но за деньги бизнеса этот самый бизнес хочет решения своих задач в той постановке и теми средствами, которые он считает для себя оптимальными. Более того, уже на этапе, когда разработчиков станет больше одного, придется договориться о том, сколько где ставить пробелов и в каком порядке модули подключать, потому что иначе кому-то обязательно придется терпеть неудобства, и поручить применение этих правил ко всем изменениям автоматике - это экономия времени и усилий всех участников-людей.
То же самое и с отсутвием goto (от которого ушли вовсе не потому, что Дейсктра такой влиятельный, а потому, что устали бороться с настоящими проблемами, вызванными его наличием и неправильным использованием, а именно с добавленными "творцами" непредсказуемыми переходами хрен знает куда, отчего рассуждать сколько-нибудь успешно о настоящем control flow стало невозможно. Да, его можно использовать правильным образом, но мы не умеем, также как мы не умеем самостоятельно управлять памятью в Си-подобных языках. Исключения, кстати, тоже выкинули по похожим причинам - переход хрен знает куда во время выполнения программы, это не только очень грустно с точки зрения производительности, но еще более грустно с точки зрения поддерживаемости, отлаживаемости, и вообще возможности понять, что в программе происходит, может произойти, и не может произойти, не запуская ее и не имея полного набора всех возможных входных данных).
Проблема "мне дали нож для масла, он тяжелый и тупой, а я хочу скальпель - он легкий и острый" - она очень старая, но у нас тут давно уже не операционная, где один хирург оперирует, а двое ассистентов подают ему инструменты и вытирают пот со лба, а мясокомбинат, в котором вчерашние студенты без опыта очень быстро, почти не думая, лепят бесконечные котлеты, стоя по колено в фарше. Индустрия давно уже успешно доказала самой себе, что среднестатистический разработчик - это человек, который ошибается просто по природе своей, и нужно сделать так, чтобы минимизировать и вред от этих ошибок, и распространение эффектов от них, сделать их как можно более локальными и заметными, либо невозможными в принципе без специальной здоровенной таблички "ОСТОРОЖНО, РАБОТАЮТ ЛЮДИ!". И goto, и исключения, и прямой доступ к оборудованию, и ручное управление памятью, и динамическую типизацию, и права рута, и доступ к внутренностям ОС, и все похожее остальное у вас отобрали чтобы защитить вас от вас самих же, а бизнес - от ущерба, который вы наносите тем фактом, что вы обычные люди, и у вас бывает плохое настроение, неудачный день, "мозговой пердеж", недосыпание, недостаток кофеина в крови и знаний в голове. Вот это все выше - не "поветрия", а неизбежность, и ограничения подобные возникают и кодифицируются при любой совместной работе множества людей над любыми большими проектами, в которых ошибки дороги, а люди - обыкновенные люди.
Не хотите работать в таких условиях - дело ваше, но я рекомендую попробовать собрать команду из десятка таких высокообразованных нехочух, и попробовать с этим всем взлететь. Попробуете, и сами придете к большей части описанных ограничений, выяснив на личном опыте, почем фунт лиха, чем статическая типизация лучше динамической, в чем проблема с исключениями, и кто морковку под землей в оранжевый цвет красит...
mpakfm
13.01.2023 12:48-2В конце 19 века люди тоже хотели 8 часовой рабочий день вместо неограниченного по желанию хозяев бизнесов. И все ваши аргументы из первого абзаца применимы и к той ситуации.
Общество самоорганизуемо и если эволюционно или революционно не сойдёт с рельсов узкой специализации винтиков,как того желает бизнес для сокращения расходов и лучшего контроля, то кто через два поколения будет создавать и творить новое? Раньше творцы росли из этих винтиков которых не зажимали. Представьте что всё для бизнеса и каждый пишет только свой код перекладывая джейсонов и так будут учить везде, на всех курсах что это правильно ибо эффективно. Откуда возьмутся новые творцы?
И система бизнес-разработки начнет деградировать, все чаще обращаясь не к вышколенным своим командам и смежникам а на фриланс. И творцы все сбегут туда. Где нет регламентов а только тз-деньги-продукт. И через какое о время эти творцы опять придут в бизнес команды рассказывая новому поколению собственников как тут все у вас отвратительно и формализовано. По новому кругу :)
CodeRush
13.01.2023 14:13+118-часовой рабочий день — это ограничение на способы ведения бизнеса, такие же, как статическая типизация — на способы писать программы. И то ограничение, и другое успешно доказали свою полезность при массовом внедрении, тем не менее, по-прежнему достаточно людей, считающих, что «за 40 часов в неделю мы ничего не успеем» (дословная цитата моего бывшего тимлида, и вообще весьма популярная идея среди окружающих меня американцев), и что «эта ваша статическая типизация — это дурацкое ограничение моей свободы самовыражения». Идите самовыражовывайтесь куда-нибудь туда, где от вас не будет вреда, торгуйте там своими шедеврами, у нас же тут вроде свобода, рынок, капитализм, вот это все.
Современное IT — это не Computer Science, это Software Development для большей части, и Software Engineering для меньшей. Мы тут ПО не «разрабатываем», мы его буквально строим из относительно стандартизированных кирпичей под руководством людей, которые учились именно строительству и именно из кирпичей. И задача этих людей в том, чтобы стройку не нужно было прекращать потому, что один из строителей попал под автобус, и построено было то, что хотел заказчик, а не то, что само как-то получилось, потому что у строителей был творческий порыв. Если вы не хотите быть строителем — ваше право, будьте архитектором, дизайнером, визионером, кем угодно, только строить не мешайте, ёкарный бабай!
Ну и по поводу мешающих жить ограничений, вот вам мнение человека, который на Расте, языке с драконовскими (по сравнению с C) ограничениями на свободу самовыражения, написал не просто мелкую утилиту, а драйвер режима ядра для видеокарты, не имея при этом никакой документации на нее.All the concurrency bugs just vanish with Rust! Memory gets freed when it needs to be freed! Once you learn to make Rust work with you, I feel like it guides you into writing correct code, even beyond the language's safety promises. It's seriously magic! ✨
There is absolutely no way I wouldn't have run into race conditions, UAFs, memory leaks, and all kinds of badness if I'd been writing this in C.
In Rust? Just some logic bugs and some core memory management issues. Once those were fixed, the rest of the driver just worked!!
AnthonyMikh
15.01.2023 17:43+1В конце 19 века люди тоже хотели 8 часовой рабочий день вместо неограниченного по желанию хозяев бизнесов. И все ваши аргументы из первого абзаца применимы и к той ситуации.
Вообще-то восьмичасовой рабочий день — это выгодно для бизнеса, потому что если заставлять людей работать слишком много каждый день, то в краткосрочной перспективе производительность вырастает, но потом падает ниже производительности на восьмичасовом рабочем дне.
kazimir17
13.01.2023 16:28+2Удивительное дело, очень часто слышу утверждение что бизнесу нужны предсказуемые результаты за предсказуемое время, но почему-то на практике бизнес делает все что б результат был предсказуемо паршивый за НЕпредсказуемое время.
Например совсем недавно один крупный и внешне успешный сервис по доставке продуктов решил переписать монолитную систему c SAP ERP на пучок микросервисов на java. Мотивация была проста: монолит сложно развивать и он тормозит, а множество сервисов можно делать независимо и они будут относительно просты и изменения вносить легче. Как итог вместо запланированных 6 месяцев на все про все, кое как уложились в 2 года и вероятно (но не точно) колоссальный перерасход средств на разработку и уничтожил успешный бизнес, остался только бренд в желто зеленых цветах.
dwdraugr
13.01.2023 20:14Бизнесом управляют люди, а они имеют свойство принимать субъективные решения. Особенно если этот бизнес ведёт не собственник, а наёмный директор, которому нужно показать прогресс и развитие технологий.
xenon
14.01.2023 02:45+3Прямо вот сердечная благодарность за "не умеем". Мне кажется, это мало кто видит.
Я просто по теме безопасности это вижу. Да, вроде бы есть много всяких советов, практик, стандартов, как все надо делать, чтобы не плодить уязвимости. Если смотреть на видимое - можно увидеть, что мы умеем не писать SQL Injection уязвимости (есть статья-книжка, как этого не делать). Умеем использовать CSRF токены. Умеем не делать уязвимости форматной строки. Судя по видимому - для всех проблем видны решения!
Но вот постоянные взломы, утечки даже из самых известных компаний (даже сегодня). И я не считаю, что программисты (или безопасники) там дураки. Вполне может быть, гораздо лучше меня все это умеют-понимают. Но просто все советы по безопасности эффективны как совет бороться со стелс-самолетами "бей лопатой по приборам навигации". Раз на практике уязвимости есть - значит писать код без уязвимостей мы НЕ умеем. И даже то, что потом можно хлопнуть себя по лбу и сказать - "ну да, конечно же, здесь надо было вот так вот написать, я это знаю" - ничего не меняет.
Можно будет сказать, что мы умеем не совершать какую-то проблему только если будет гигант вроде яндекса и во всех его проектах за последние N лет этой проблемы не будет - тогда умеем, да. (Например, атаки на срыв стека в этом смысле побеждены).
CodeRush
14.01.2023 03:45+1Атаки на срыв стека в этом смысле побеждены
Да если бы, блин горелый! Побеждены они буквально в паре программ, которые непрерывно атакуют, а там, где атакуют чуть менее яростно — цветут пышным цветом.
Никто там не дурак гарантировано, основная проблема в том, что вообще говоря проблемы компьютерной безопасности практически ортогональны проблемам разработки ПО.
Задача безопасника гораздо шире задачи разработчика, потому что последнему нужно, чтобы программа, грубо говоря, выдавала ожидаемый результат при ожидаемых входных данных за ожидаемое время. Платят ему именно за это, и спрашивают именно за это, и инструменты его под это заточены. Безопаснику же нужно, не навредив «правильному» пути в этом огромном дереве принятия решений, отрубить как можно больше ветвей, ведущих к исполнению произвольного кода, который атакующий каким-то образом желает исполнять. А если у нас программа еще и с секретными данными работает — дополнительно предотвратить утечку этих данных по каким-либо сторонним каналам. Т.е. борьба и с возможностью и перехода программы в «неожиданные» состояния, и с возможностью сборки из таких состояний и переходов т.н. weird machine.
Вот эти задачи — они кратно сложнее «обычного» программирования, и именно они приводят к требованиям и ограничениям, которые «обычные» разработчики потом яростно ругают за то, что они ограничивают полет их мысли и свободу их самовыражения, не понимая, что без этих ограничений, процессов, линтеров, статических анализаторов, компиляторов, и прочего тулинга даже минимально безопасное ПО написать буквально нельзя, потому что комбинаторный взрыв, потому что бизнесу это ПО нужно уже сегодня, и потому что мы тут такие же люди, как и «обычные» разработчики, и ограничены таким же образом.
Вся история компьютерной безопасности — это история борьбы все более сильных ограничений со все более изощренными методами их обхода. При этом цели сделать 100% безопасно не ставится никогда, достаточно, чтобы ценность защищаемой информации была ниже, чем стоимость неправомерного ее получения при помощи все более хитроумных (а потому все более дорогих) технических средств. И пока что, даже несмотря на буквально миллиарды долларов вложений и миллионы человеко-часов далеко не самых глупых человеков, получается у нас примерно вот так.xenon
14.01.2023 19:07Срыв стека побежден в том смысле, что если вы его прямо вот очень сильно не хотите - вы просто пользуетесь простым языком без malloc() и strcpy(), каким-нибудь PHP или пайтоном - и все у вас будет хорошо. Достаточно просто распорядиться, на бумажке подписать указ "пишем проект на пайтоне", и срыва стека не будет. Есть ничтожная вероятность, что он будет в самом пайтоне, но и эта проблема решится дешево, просто апгрейдом на пропатченную версию. Да, это не абсолютно, но вполне близко к тому. Уязвимы те, кто до сих пор пишут на С, но они знают и принимают этот риск.
И мне кажется, это очень хороший подход. Нечто подобное есть в веб-программирований. Полно типовых LAMP сайтов и бэкендов сделанных студентами, в них куча дыр, но при этом вряд ли через какую дырку можно получить доступ к другой базе данных в этом же MySQL и вряд ли можно выйти за пределы юзера www-data.
Когда мы безопасность "аутсорсим" отдельному маленькому стабильному компоненту, (например, код аутентификации в MySQL) он у нас один раз вылизан до идеала, и дальше мы можем на него полагаться. Сайты пишем разные, но вот mysql и ядро с файлухой используем готовые, поэтому нарушить их барьеры практически невозможно.
SquareRootOfZero
13.01.2023 10:13+13Что такое микросервис, значительная часть которого кодогенерируется? Это способ изолировать разработчика от целого (и друг от друга). Это жёсткий контракт в YAML-файлах: «На входе требуется вот это, а на выходе вот то, приступай!». И даже внутри оставшихся двадцати процентов свобода творчества самым садистским образом ограничена: цензурируется шестью с половиной линтерами!
Но ведь вполне здравая идея — изолировать и абстрагировать задачи, чтобы разработчик не был вынужден сперва пару месяцев втыкать в весь имеющийся codebase, а мог работать в формате «вход-выход-приступай». Да и линтеры правда ли такое уж зло — нужно ли другому разработчику, если мы от него всё же не смогли до конца изолироваться, ломать глаза, проникаясь нашим творческим стилем кода, или всё-таки лучше видеть привычные вещи в привычных местах в привычном формате? Пример если что и показывает, так это то, что любая, даже здравая в основе своей идея, будучи доведена эффективными менеджерами до состояния самоцели, может превратиться в бессмысленный вредный маразм. Ну так а что у нас, будучи доведено до состояния самоцели, не может превратиться в бессмысленный вредный маразм?
Вообще, можете зачитать статью в аудио-формат голосом Ленина, и чтобы там ещё были всякие «батенька» и «аrхиважно»? Типа: «Товаrищи! Аrхиважно написать пrепrоцессоrы для Go и Rust, rеализующие синтаксис исключений! Немедленно захватить и ценой любых жеrтв склеить в монолит все микrосеrвисы!»ednersky Автор
13.01.2023 10:22+4Но ведь вполне здравая идея — изолировать и абстрагировать задачи, чтобы
разработчик не был вынужден сперва пару месяцев втыкать в весь
имеющийся codebase, а мог работать в формате «вход-выход-приступай».только тот же спектр задач, что раньше решало пять человек, в новой парадигме решают 150 и в значительно большие сроки...
И ценность для бизнеса в том, что 150 одним днём можно заменить на другие 150.
а так-то да, вы правы.
SquareRootOfZero
13.01.2023 20:31Даже если это у вас не гипербола про 150 человек вместо 5 и про 24 человеко-года вместо одного человеко-месяца, подозреваю, дело не в «смене парадигмы», а в раздувании штата вслед за раздуванием ЧСВ: одно дело, когда ты просто сказал Васе и Вася за месяц всё сделал, и совсем другое, когда ты годами руководишь отделом из 150 человек. А байки про «ценность для бизнеса» — это так, пост-рационализация.
ednersky Автор
13.01.2023 20:35-1А байки про «ценность для бизнеса» — это так, пост-рационализация.
бизнес ведь это оплачивает? оплачивает
в больших компаниях повсеместно это внедряется? внедряется
а то что движущие мотивы у каждого свои - это ведь явление вторичное. Первичное - куда направлен вектор.
auresio
13.01.2023 10:23Но ведь вполне здравая идея — изолировать и абстрагировать задачи, чтобы разработчик не был вынужден сперва пару месяцев втыкать в весь имеющийся codebase, а мог работать в формате «вход-выход-приступай».
Изолирование/логическое стуктурирование/переиспользование/универсальность кода = хорошо. Урезание видимости задачи человеку/разрыв контекста/зацикливание на стандартах и паттернах/ограничение самовыражения = плохо.
abyssSoft
13.01.2023 10:49Я не знаю как вам, но думаю многим специалистам не очень нравится работать по методу "мог работать в формате «вход-выход-приступай».". Я разработчик уже более 20 лет, за всю мою историю работы я не встречал хороших специалистов, которым бы нравился такой подход. Он же уничтожает личность человека, уничтожает его желание создавать. Зачем тогда идти работать разработчиком, если ты это не любишь и тебе это не нравится? Можно устроится намного проще, где не надо постоянно изучать новое, постоянно быть в "теме", постоянно учить. А если ты любишь свою работу, она приносит тебе удовольствие, значит и такой подход терпеть нельзя.
Что касается микросервисов, то я не думаю что все они плохие и их "надо запретить". Надо просто с головой подходить к проблеме которую мы решаем и уже от нее смотреть какое решение нам подойдет, если подходит микросервис - используем его, если монолит, значит применяем монолит. Это же касается и языков программирования. Просто я думаю что нельзя так категорично утверждать что "это плохо", а вот "это хорошо", мир разный и каждому найдется свое применение.
SquareRootOfZero
13.01.2023 16:24+3Мне вообще больше всего нравится работать в одиночку — сам начал, сам закончил, сам всё придумал, спроектировал, реализовал, захотел — апи переколбасил, захотел — всё отрефакторил, как тебе нравится, красота! Но даже достаточно небольшие проекты, которые реально за вменяемое время затащить в одно рыло, имеют тенденцию усложняться так, что никакой творческий рефакторинг сам по себе не спасает. Про большие проекты, которые в одно рыло нереально, уж что и говорить. Единственный, по-сути, метод, который человечество изобрело для борьбы с подобной сложностью — это black box abstraction. Как по-другому ни назови и в какой парадигме ни оформи (функции, классы, пакеты, модули, сервисы, интерфейсы, и т. д., и т. п.) — суть одна: вот вход, вот выход, в середине чорный ящик, надеемся, что он работает правильно, преобразуя любой допустимый вход в соответствующий выход, потому что держать постоянно в башке все детали реализации всего нереально, никакой башки не хватит. Каким местом этот подход (единственно возможный, вообще-то) уничтожает личность и желание создавать? Я правда предпочитаю работать в формате «вход-выход-приступай» над коллективными проектами, да даже и если в одиночку допиливать чужие проекты — это просто наиболее рациональная и вменяемая постановка задачи, в противном случае, как правило, там получается что-то вроде «вот возьми эти километры говнокода, вдумчиво раскури, сам там нащупай вход-выход, и тогда уже приступай».
volatilization
13.01.2023 10:24+22Автору удалось разбудить быстрее и лучше чашки кофе.
Боли процедурного программирования под марксистским соусом - какой-то сюр, честное слово.
Конечно, разработка - творческий процесс. Но если ты часть бизнеса, то уважай его. Не хочешь - иди в другой, слава Богу не при социализме живем.ednersky Автор
13.01.2023 10:24+1Но если ты часть бизнеса, то уважай его
я вот не понимаю этого если-то
baldr
13.01.2023 10:43+1А чего тут не понимать, тут же к вам
gotoприменили: "if не хочешь goto другой"
volatilization
13.01.2023 10:55+2Это звучит подло, разве нет? Бизнес смог наладить процессы так что бы платить деньги. Если я не могу наладить такие процессы сам, то мне есть за что уважать бизнес. Я не про процессы разработки.
SteamEngine
13.01.2023 10:24+3Я не хочу учить джаву. Хочу писать микросервис на питоне, в который заверну свою нейросетку.
polar_yogi
13.01.2023 11:10+7ИМХО, по поводу "пролетарии всех стран" вы немного не к той целевой аудитории. Пролетариат был готов бороться, потому что ему нечего терять кроме своих цепей. Программисты, и в целом ИТ специалисты, сейчас одна из самых оплачиваемых категорий наемных работников. Хотите убедить их что лучше бороться за светлое будущее, чем зарабатывать приличные деньги прямо сейчас?
Вспомните недавний случай, rambler vs nginx, как отреагировало ИТ сообщество? Примерно никак, побурлило в комментах. Кто-то пытался предлагать разработчикам видеосервиса rambler встать и уволиться, на что они сказали, в приблизительном переводе на русский: "нам жаль, если кто-то пострадает, но у нас успешный бизнес, широкая аудитория, большие зарплаты. да вы охренели."
Кроме того, борьба это не только либиртэ-игалитэ-плюсвкарму, но и "порой прозябая по тюрьмам сырым ... и шли мы гремя кандалами". У нас, как бы, капитализм, соответственный правящий класс, поэтому условный рамблер может написать в полицию "у нас украли миллион" и к разработчикам придут люди с автоматами, изымут имущество и заблокируют счета, а через полгода скажут - отсутствует состав преступления, вы свободны. А условный разработчик, который потерял миллион в результате этих действий - нет.
Выбор который предлагаете вы выглядит примерно "бороться с режимом и получить двушечку вместо зарплаты" или "писать микросервисы без гоуту и исключений и получать высокую зарплату, пока есть возможность". Прикольно, чо? Впятницу утром бодрит лучше чашки кофе
Manson
13.01.2023 15:51+1Автор как раз шуточно предлагает "НЕ писать микросервисы С гоуту и С исключениями и изменить мир, чтобы зарплата была не нужна!" :-)
DenisPantushev
13.01.2023 11:14+21Боже мой! Дожили! Неужели же ИТ движется в правильную сторону?!!
Ладно, спокойно. Я когда-то уже комментил, и готов посторить сейчас: ИТ (по крайней мере до этого момента) находится в состоянии допромышленного производства. Грубо говоря, средневековье с мастерами и цехами. В то время, как производство материальных ценностей уже начиная с петровских времен находится в состоянии нормального промышленного производства.
Уже начиная с Петра 1, производство ружей делалось в такой вот "микросервисной" манере - каждый мастер точил только одну определенную деталь. По чертежу, строго по размерам. Можно было разобрать десять ружей, перемешать детали и собрать снова десять ружей, и они будут нормально функционировать и стрелять. Если мастер по замкам уволится, он не сможет сделать ружье самостоятельно. Драма это? Трагедия? Нынешние рабочие точат на определенных станках определенные детали и даже подумать не могут, что могут выточить трактор целиком, если уволятся. Драма это для них? Трагедия?
Почему же для айтишника это трагедия?
Все проблемы ИТ - это средневековая отсталось организации производства, я гарантирую вам это. В программировании нет разделения труда, бекэнед/фронтенд - это вообще не разделение. В программировании нет тотального контроля результатов труда. ТДД - это полная ахинея, я уже писал. ТДД сравнивает результат труда программиста не с чертежом, а с тестом. Не может исполнитель проконтролировать свой продукт. Контроль должен осуществляться ВСЕГДА сторонним человеком, причем это должен делать не разработчик проекта, а специально обученный контролер - тестировщик. В программировании царит тотальная самодеятельность. Понятия проектов (чертежей) в подавляющем числе контор не существует, либо они крайне размыто составляются и программисты крайне вольно раеализуют свои поделки, зачастую очень отдаленно реализующие проект. Да еще и продвигается мысль, что проекты - зло.
То, от чего так бомбит автор - отчуждение результатов труда от исполнителя - это нормальный процесс развития производства. В машиностроении это было реализовано триста лет назад (Маркс только описал). Рабочие на заводе ходят на работу не для того, чтобы самовыражаться. Они делают работу, точат детали (строго по чертежу) и получают за это зарплату. В ИТ почему-то творится дичь. Приходит программист и предлагает прикрутить к огромной системе какую-то фиговину сбоку, в пятьдесят строк кода, ага. Которая решит все проблемы.
Его правильно обломали. Есть чертеж изделия (к примеру ракета или ускоритель). По нему исполнитель должен в точности выточить все детали (классы). Детали тщательно проконтролируют и соберут из них узлы (микросервис). Узлы(Микросервисы) соберут в единую систему, которую можно будет запускать в космос (в продакшн). И тут приходит дядя Вася (талантище!) который предлагает "Давайте тут приварим фигнюшку! Ракета баще полетит!". Какие слова прозвучат при этом предложении?
engine9
13.01.2023 12:01+3Когда промышленность использует человека как заменимую часть конвейера то начинает страдать психика человека. У нас почему-то психическое здоровье людей традиционно низводилось до каких-то презренных розовых соплей, которые волнуют только неженок. Но нас эволюция готовила немного под другие задачи по типу "сообща командой завалить мамонта" или "обхитрить группу противника".
Видимо из за этого так популярен футбол и командные компьютерные игры. Мозг не просто так тяготеет к творческим задачам...
xenon
14.01.2023 01:06+1Возможно. А когда пожарный на работе в огонь лезет - начинает страдать кожа пожарного, а то и до костей сгореть может. Но кому не нравится - могут работать в других сферах.
Первична какая-то бизнес-потребность, и уже для ее решения нужны программисты, тимлиды, ПМы и прочие. Но не наоборот, не ради счастья программиста все это придумано.
Главная мысленная таблетка от излишнего "социализма" - роботизация. Вот ныли раньше рабочие на какой-нибудь фабрике, что им мало платят за тяжелую работу по шитью кроссовок, угнетают их, эксплуатируют - появляется полностью автоматизированная линия и их уже не эксплуатируют. (Могут радоваться). Их очень легко заменить. Программистов сложнее, но, возможно, очень скоро и мы будем под вопросом, и никто уже не будет мучать нашу психику неприятной работой. Какой-нибудь AI заменит 80% программистов.
engine9
14.01.2023 13:16не ради счастья программиста все это придумано
Вот в этом принципиальная разница наших взглядов на труд. Я уверен, что бизнес и организация должна быть "для счастья программиста", а не "человек — топливо для бизнеса".
Думаю, что и сейчас полно желающих работать руками и головой, но не в качестве винтика в системе. Ведь можно организовать труд людей таким образом чтобы к рутине подмешивалась некая часть творчества, чтобы сотрудник чувствовал своё небольшое но влияние на общее дело. (Как это происходит в небольших командах, где каждый ответственен за свой участок работы).
xenon
14.01.2023 19:14Но я не вижу тут проблемы. Можно ведь не работать винтиком в большой компании если не нравится. Работать в маленькой компании. А другим наоборот, кому-то хочется один раз глубоко выучить одну свою тему и в ней до пенсии работать. Им это творчество нафиг не нужно, им хочется с 9 до 5, по четким правилам, чтоб как на госслужбе.
Это как с барами-кафе-ресторанами. Не надо разрабатывать кодекс, правила для меню, стандарты на размеры столов итд, а потом всех заставлять их соблюдать. Нет, пусть цветут все цветы. И то что вам 9 из 10 баров не нравятся - ну и ладно. У вас будет свой любимый веганский бар для тех кто с детьми и пришел курить, гладить кошек и слушать норвежскую музыку.
engine9
14.01.2023 21:01А что если не все цветы цветут и у людей не может быть выбора? Например в небольших городах. Вот в вашем городе много сравнимых вакансий, чтобы все кто не хочет работать винтиком имели возможность начать работу на новом месте?
xenon
14.01.2023 22:10+2Страдать. Вот я, например (в душе, по вкусам, предпочтениям), знаменитая мировая поп-певица и икона стиля. Но в моем городе меня не знают, не ценят, платить за это не желают (а я бы спел). Особенно люди с музыкальным образованием не любят мои песни. И мне приходится страдать и все вот эти ваши пайтоны, линукса и хттп. А мне летать, а мне летать охота. Если уж такая супер-звезда как я страдает и унижается то IT ремесла - и они не развалятся.
Как только собес будет мне платить (или законять бюджетников на концерты с билетами, как на роллинг-стоунз) достаточно, чтоб хватило на шлюх, к.каин, частный вертолет и еженедельный разгромленный номер в отеле - дальше можно уже позаботиться будет и о тех, кому хочется не одну технологию программирования, а другую.
engine9
14.01.2023 23:12Я удивлён как вы защищаете негуманную систему. Если честно, было трудно продраться через дымовую завесу софистики и неуместных аналогий...
0xd34df00d
15.01.2023 05:13Что лучше — негуманная реализуемая система или гуманная нереализуемая?
engine9
15.01.2023 11:29А почему гуманная нереализуема? Опять какие-то ложные дихотомии
и защита рабами своих оков.AnthonyMikh
15.01.2023 17:58Ну чёт несколько раз гуманную пытались реализовать, каждый раз выходила какая-то какашечка. Последний такой эксперимент затянулся лет на 70, последствия до сих пор разгребают.
engine9
15.01.2023 18:11Выборка мала. Первые самолёты падали и убивали своих пилотов, но люди не перестали развивать авиацию.
iig
15.01.2023 21:59Если бы любители построить справедливое общество ставили свои социальные эксперименты исключительно на себе - это было бы замечательно.
engine9
16.01.2023 00:44Ожидаемо все скатилось в демагогию (в т.ч. с моей стороны). Но я не понимаю почему многие в этом треде продолжают так настойчиво защищать свои вериги и отношение бизнеса к работнику как к мясу.
Kanut
16.01.2023 00:50Ну всё-таки далеко не весь бизнес относится к работникам как к мясу.
С другой стороны отношение работников к бизнесу тоже далеко не всегда идеальное :)
ednersky Автор
15.01.2023 19:54-1Ну чёт несколько раз гуманную пытались реализовать, каждый раз выходила какая-то какашечка.
всякий раз антигуманисты гадили так, что
-- проводили мировые войны на территориях где такое пытались реализовать
- сочиняли 100500 небылиц, которые теперь официально записаны в учебники (например: секретные дополнения к пакту Молотова-Риббентропа, или скажем: миллионы жертв ГУЛАГа. Последнее впервые сочинено Гитлером в произведении Майн-Кампф, а затем творчески переработано и удвоено (по числу жертв) Солженициным и ко)
- устраивали экономические и прочие блокады (Куба, Корея так до сих пор в блокадах, а Корея так ещё и разделена на две), ограничивали доступ к технологиям.
- организовывали гонки вооружений, итп
СССР в таких условиях продержался, как вы изволили выразиться, 70 лет, потому, что удалось контролировать довольно много ресурсов.
Кстати, это противостояние со всем миром показало, что теоретики, считавшие, что нужно делать мировую революцию (и проигравшие тем, кто считал, что мы свою страну сумеем отстоять), были в чём-то правы.
PS: А наложенный на нас извне железный занавес, вполне дал плоды. Люди привыкли к тому, что СМИ рассказывают им правду, а затем когда занавес приподняли и хлынула муть, получились такие как вы, рассказывающие всем про какашечки и главное: верящие в эту хрень- проводили мировые войны на территориях где такое пытались реализовать
iig
15.01.2023 22:07+1проводили мировые войны на территориях где такое пытались реализовать
Причинно-следственная связь сломалась.
или скажем: миллионы жертв ГУЛАГа. Последнее впервые сочинено Гитлером в произведении Майн-Кампф
Майн-кампф написан в 1925-1926 году. Гулаг начали организовывать в 1929 году. (даты взял из открытых источников). Этот Гитлер тот ещё провидец оказался ;)
ednersky Автор
15.01.2023 22:29-1> Майн-кампф написан в 1925-1926 году
я бы дал сюда цитату из него, но это запрещённая литература.
если скачаешь — можешь поиском внутри поискать по слову «репрессировано и убито тридцать миллионов».
во время войны Геббельс увеличил эту цифру в полтора раза в своей пропаганде, ну а Солженицын довёл её до шестидесяти (ЕМНИП).
> Этот Гитлер тот ещё провидец оказался ;)
в плане пропаганды-то? конечно. все запущенные им мульки работают до сих пор, как и созданные им бандеровцы и проч.
вот снова приходится с этим воевать. увы
xenon
15.01.2023 16:32Что же сложного? Давайте я помогу. Вы хотите быть программистом, делать что-то конкретное (а не то, что от вас хочет злой наниматель) и получать за это хорошие деньги (в отрыве от рыночного спроса на это действие). А я хочу быть Софией Ротару, ездить с гастролями, собирать полные залы, принимать цветы, ну и получать за концерт соответственно. И мое и ваше желание не сбывается сейчас. Почему вы считаете ваше желание более важным, приоритетным, чем мое?
В "негуманных системах", как мы видим на практике, всем ущемленным группам (пенсионеры, инвалиды, безработные) - живется гораздо лучше чем в "гуманных" системах.
gatoazul
14.01.2023 14:45+1А бизнесменов можно заменить роботами?
xenon
14.01.2023 19:16В каком-то смысле. Посмотрите на магнит, типичный управляющий магнита делает почти те же функции, что и хозяин небольшого магазина. Просто исполняет программу.
Но в другом смысле невозможно, потому что бизнесмен рискует своими деньгами, когда вкладывает их в какой-то бизнес. А робот так не может, потому что у робота своих денег нет. Робот может, например, заказать новую партию товара, но вот рисковать он не может, ему нечем. :-)
engine9
14.01.2023 21:02А что даёт риск человеку и не даст роботу?
xenon
14.01.2023 22:15Обратную связь. Хороший предприниматель сегодня открывает ларек шаурмы, через год у него сеть ларьков, а через 10 лет ему все рестораны лас-вегаса принадлежат. Потому что он умеет каким-то образом делать хороший общепит и превращать один доллар в десять. А кто не умеет - тоже полон идей, но как только проверяет их, открывает свою первую шаурмячную, и остается ни с чем.
Но на самом деле я чуть преувеличил. Дурак (там, внутри себя) понимает, что он дурак. Ему нравится обманывать себя, будто бы он умный, но как только дело доходит до того, чтобы вложить 100 тысяч и своим умом получить из них миллион - что-то в дураке говорит ему - "не надо, ты же дурак, твои идеи - говно, они не взлетят" - и он не вкладывает.
Вот у робота нет ни денег, ни внутреннего голоса, ни страха потерять деньги.
gatoazul
15.01.2023 13:08Кто мешает дать роботу свои деньги или ввести какие-то иные квоты на его деятельность?
i86com
15.01.2023 17:59+1Разница в том, что «придумать и описать словами функцию детали», «начертить точный чертёж» и «выточить 500 таких деталей» — очень разные работы и вполне понятно, почему их делают разные люди, а не один и тот же человек. Так тупо эффективнее.
А вот «изучить баг/фичу», «разобраться и придумать, что именно нужно переписать в коде» и «переписать код» разделять между людьми неэффективно — тут возникает ситуация, когда «самому сделать занимает 5 минут, а объяснять кому-то другому — 5 часов».
И с тестированием порой та же ситуация. И с нестрогим разделением на бэкенд/фронтенд.
А так, если максимально разделять, то можно дойти и до «кодеров», каждый из которых умеет дописывать в файл лишь один определённый символ и «начальника отдела кодинга», который в правильном порядке отдаёт команды, чтобы написать программу — полное разделение «творчества» и «кодинга». Вот только творчества в такой системе останется столько же (оно просто перейдёт на уровень выше), а затраты и время на коммуникации повысятся.
Javian
13.01.2023 11:23+1Микросервисы - это современный конвейер. Каждый рабочий на конвейере выполняет свою маленькую задачу. Вообще история автопромышленности это история любой современной индустрии. По ней легко увидеть куда идет и IT в том числе.
XelaVopelk
13.01.2023 11:57+2А до конвейера, были фабрики, а до этого мануфактурное производство:
https://www.marxists.org/russkij/marx/1867/capital_vol1/25.htm
"...После разделения, обособления и изолирования различных операций рабочие делятся, классифицируются и группируются сообразно их преобладающим способностям. Если, таким образом, природные особенности рабочих образуют ту почву, на которой произрастает разделение труда, то, с другой стороны, мануфактура, коль скоро она введена, развивает рабочие силы, по самой природе своей пригодные лишь к односторонним специфическим функциям. ..."
dyadyaSerezha
13.01.2023 11:33+3Я не понял главнго. Рост деструктивных паттернов в программировании - результат злых капиталистов и отчуждения труда писателей микросервисов? Риалли?
vadimr
13.01.2023 11:49+3Например, один из микросервисных программных продуктов, разработанных под моим руководством, пишет географически распределённая команда разработчиков в течение примерно 15 лет. Большинство из первоначальных участников проекта поувольнялись. Поменялось железо, операционная система, средства разработки, отчасти языки программирования. До кучи поменялось юридическое лицо.
Кто и как тут должен был бы собирать монолит?
Думаю, что Яндекс.Такси тоже устроено непросто.
Начало статьи хорошее, а в итоге автор почему-то взъелся на микросервисы, хотя претензии у него были к регламентам.
engine9
13.01.2023 11:52+2Я не программист, но мне кажется проблема общечеловеческая и выглядит как повторяющийся шаблон: "Мы придумали новую парадигму и начинаем внедрять её везде где можно как новую идею, способную решить все проблемы!".
Потом когда общество уже не может отрицать очевидные проблемы и нестыковки то начинается пересмотр (иногда весьма болезненный или даже кризис) и выдумывание новой очередной сверхидеи.
А разгадка проста — человек мыслит эмоциями и авторитетами, а лозунги являются чем-то вроде информационных паразитов мышления.
im_last
15.01.2023 02:08+1Это называется проще - когнитивные искажения, просто из них описана только часть.
Но даже та, что описана, выглядит монструозной.
Картинка взята тут
engine9
15.01.2023 11:36Думаю, что без них не обошлось. Ха! Забавно. Ткнул в случайное место на картинке и попал точнёхонько в "оправдание системы". Выше в комментариях несколько наглядных примеров, в духе "Надо продолжать страдать", "Роботу удавку на яйца в виде мат. ответственности не накинуть, а человеку — можно" и все в таком духе.
13oz
13.01.2023 12:22+6Отчуждение труда
Разве за использование марксистской лексики еще не начали бить канделябром?
Увы, новые вещи (коих не так чтобы вообще есть16) всё чаще приносят с собой и очевидно деструктивные, будто навязываемые извне, паттерны.
Новые вещи есть, но их нет, понемаю. Правда, потом автор вспоминает про несуществующую новую гошечку, но ее же нет. Хотя она есть.
В общем, как-то раз один с виду вроде бы неглупый человек ляпнул в
публичном пространстве совершенно необоснованное суждение "о вредности
оператораgoto"Вредность оператора goto - в том, что получается лапша, а не код. То, что есть случаи, когда его использование позволяет выиграть несколько тактов - это, конечно, замечательно. Было. Лет 40 назад. Сейчас его недостатки перевешивают достоинства.
А ещё в наше пространство вторглись линтеры, не только верифицирующие
код на предмет возможных ошибок (что в целом хорошо), но и указывающие
нам, "сколько пустых строк ставить между блоками", или "в каком порядке
импортировать модули15!"Линтер выдает рекомендации по code-style, ужас! Заставляет писать так, что бы тебя потом поняли другие - возмутительно!
И вот, крупная международная корпорация, для разработки нового
инструмента привлекает одного некогда умного, но ныне довольно
старенького, ставшего маразматиком, специалиста. И всё бы ничего, но
только он толкнул в массы новую "мегаидею" (по аналогии с "goto— это плохо"): "Исключения — это плохо!"4.Это место просто офигенное. Авторы решили, что исключения как отдельная сущность не то, что бы нужны, и выкинули их. Вроде, где-то даже был rationale, почему так. Это называется "поиск идей". Правда, выше автор говорил, что нового не бывает, а тут у нас уже новое, ну да ладно.
С технической точки зрения (производительность, количество кода и т.п.), микросервис всегда может быть замещён обычным кодом, и это действие приведёт к тому, что накладные расходы упадут, а эффективность вырастет.
Серьезное заявление. Обосновывать ты его, конечно, не будешь
На самом деле, дальше я уже даже не знаю, что комментировать, потому, что там смешались в кучу кони, люди, BLM, SJW, Маркс, Руссо и свобода творчества.
Если попробовать вернуться к сути. Программирование за деньги - это ремесло. Это не искусство, где автор самовыражается на потеху себе и/или публике. Это ремесло, работа, профессия, как строительство, ремонт автомобилей и покраска заборов.
Два. Вам не нравятся новые подходы в программировании и хочется самовыражения? Вас ждет увлекательный мир опенсорца и большого количества языков программирования, включая эзотерические.
Итого. Я вообще не понимаю, что хотел сказать автор, и зачем.
ednersky Автор
13.01.2023 12:42+4Разве за использование марксистской лексики еще не начали бить канделябром?
буржуазия пыталась продвигать необходимость такого действия, однако "ветер истории неизбежно сметает нанесённое".
Вредность оператора goto - в том, что получается лапша, а не код.
а полезность в том, что из лапши можно сделать код (парсеры, стейтмашины, оперирование связанными ресурсами итп)
13oz
13.01.2023 12:49+3буржуазия пыталась продвигать необходимость такого действия, однако "ветер истории неизбежно сметает нанесённое".
И именно поэтому марксизм отправился именно туда, где ему самое место - в музей
а полезность в том, что из лапши можно сделать код (парсеры, стейтмашины, оперирование связанными ресурсами итп)
А можно сразу написать код и не сношать мозги себе и окружающим
anone18236
13.01.2023 12:32+3Нелюбовь к микросервисам, скатывающася к псевдонаучным теориям. В данным момент 10 плюсов у статьи. О времена, о хабр!
Пользуясь случаем, хочу заметить, отличный механизм кармы на ресурсе. Прям видно какая у ресурса становится аудитория, и какой контент она хочет видеть.
13oz
13.01.2023 12:49+5Да ладно, судить по аудитории по одной пятничной статье не стоит. Все любят жырные набросы
HellWalk
13.01.2023 12:32+1У всего есть свои плюсы и минусы, и нужно понимать что где использовать.
Например, есть задача сделать новый проект и команда в 50 бэк-разработчиков (и объем функционала соответствующий) - делать проект монолитом - это погрязнуть в бесконечные споры по коду и мерж-конфликты. Плюс сложность входа для новых программистов будет заоблачной.
Если же разрабатывается новый проект с 1 бэк-разработчиком, и если поделить проект на 30 сервисов - то проект никуда не сдвинется. Потому что только по одному взаимодействию этих 30 сервисов придется сделать большой объем работы, с которым 1 программист не справится.
Ну и еще есть куча особенностей (той же невозможности одному программисту своровать весь проект, когда есть доступ только к одному сервису и все) и тонкостей.
ednersky Автор
13.01.2023 12:46+1Например, есть задача сделать новый проект и команда в 50 бэк-разработчиков (и объем функционала соответствующий
здесь противоречие.
вам что нужно: сделать новый проект (читаем Брукса, задача о 5 разработчиках) или озадачить работой 50 бэк (и 50 фронт) разрабов?.
auddu_k
13.01.2023 12:41+3Свобода - это осознанная необходимость
Если ты осознаешь зачем тебе тут goto и можешь сделать так, чтоб поняли коллеги - пиши goto.
Если ты считаешь, что нужна штучка с postgre и можешь это обосновать (архсовет или что-то там) - делай.
ИТ абсолютно свободен, просто промышленный ИТ не для одиночек, а для команд и чем больше команда тем сложнее (а чаще всего просто лень) вот это «обосновать».
В итоге поленился и решил, что проще поменять место работы, как-то так выглядит ????♂️
fe3dback
13.01.2023 13:11+2За обработку ошибок в rust и go обидно. Не понятно почему автор воспринимает возможные ошибки в программе, как "грязь", как будто там код подгадился:
И теперь тысячи — нет, уже миллионы — программистов в каждой первой функции пишут повторяющийся код, засоряющий пространство на экране
Если вы пишите что-то серьезное, где не хотелось бы терять данные пользователей просто так, то ошибки такая же важная часть кода, как и бизнес логика, и им нужна нормальная поддержка со стороны языка и синтаксиса.
Как исключения вам помогут? Максимум у вас код в проде упадет где-то, вы это залогируете из эксепшена, и потом в этом месте добавите логику для фикса бага. Но данные уже не вернуть.
В go/rust вы сразу знаете все места где у вас упадет код, и в зависимости от контекста и важности функции, сразу можете корректно обработать этот случай.
ednersky Автор
13.01.2023 13:12Если вы пишите что-то серьезное, где не хотелось бы терять данные
пользователей просто так, то ошибки такая же важная часть кода, как и
бизнес логикатут согласен.
непонятно только зачем обработкой ошибок загромождать программисту работу над собственно алгоритмом?
sicikh
13.01.2023 19:12Для прототипирования алгоритма в Rust, например, придумали макросы
todo!()иunimplemented!(), которые говорят компилятору, чтобы он не задирался на неудовлетворённые типы.А обрабатывать ошибки придётся в любом случае, сейчас или потом :)
anone18236
13.01.2023 13:28Вопрос- как без исключений решить следующую проблему:
Обработка пользователей в цикле
Падает ошибка, один из пользователей по какой-то причине не валидный
цикл прерывается, все пользователей после него не обрабатываются
При наличии эксепшенов, просто заворачитваетс в try catch, и ошибка не останавливает весь цикл.Что делать без использования эксепшенов? Навешивать if на все поля, на все возможные случаи (что уже на грани фантастики, "как писать без багов")? Как это решится в go/rust?
ksbes
13.01.2023 14:00для этого придумали Maybe и всякие другие Optional'ы — Result'ы
А вот как вы в преведённом вами примере вернёте из метода отделный список ошибочных пользователей, чтоб вышестоящий алгоритм или человек мог с ними что-то сделать?anone18236
13.01.2023 14:20А можете пример привести? Потому что go не знаю, а быстро не разобраться.
Не получится ли так, что через maybe и optional можно предусмотреть только те ошибки, о которых ты можешь подумать? Меня интересует случай, когда ошибка случается, то есть та, которую не предвидели. Цикл прервется или нет, с использованием методов maybe и optional, при возникновении непредусмотренной ошибки?
А вот как вы в преведённом вами примере вернёте из метода отделный список ошибочных пользователей, чтоб вышестоящий алгоритм или человек мог с ними что-то сделать?
А никак. Только у вас вопрос демагогический немного- необязательно возвращать отдельный список, что бы с ним что-то сделать. Если сразу хочется, в обработке исключения можно ложить в лист, после цикла у вас будет список необработанных пользоветелей. Или помечать в базе через флаг, что бы не потерялся, и потом уже с ним работать.
sicikh
13.01.2023 19:38+1Обработать весь массив пользователей, а затем вернуть массив невалидных пользователей:
pub fn process_users(users: Vec<User>) -> Result<(), Vec<ProcessError>> { let mut errors: Vec<ProcessError> = Vec::new(); for user in users.iter() { if let Err(invalid_user) = process_user(user) { errors.push(invalid_user); } } if errors.is_empty() { Ok(()) } else { Err(errors) } }Обработать массив пользователей и прервать обработку при первом невалидном пользователе:
pub fn process_users(users: Vec<User>) -> Result<(), ProcessError> { for user in users.iter() { process_user(user)? // или более многословные конструкции } Ok(()) }А если ошибка непредусмотренная, то получается, что и восстановиться соответствующе мы от неё не сможем — здесь либо
unexpected_error.map_err(|source| MyError::Unexpected { source })?, который завернёт ошибку в какой-то наш тип ошибки, от которого мы восстанавливаемся «в общем порядке», либо повесить поток черезpanic!("Unexpected error"), чтобы не распространять неопределённое поведение дальше по программе.anone18236
13.01.2023 20:34Жесть то какая.
На моем текущем проекте (java/kotlin) есть порядка 30 подключенных по ресту рекламных сетей, занимающихся маркетингом. Они все имеют своё апи. Им шлются юзеры, регаются, потом они опрашиваются, от них по апи приходят статусы. У нас все это завернуто в for. Иногда они в одностороннем порядке меняют апи (урлы, респонсы), и естественно валятся ексепшены. Но, так как в цикле каждая итерация завернута в try catch, отлетает только один брокер.
Теоритически это можно и на go сделать, как я понял заворачивать в потоки, и я так понимаю отслеживать состояние, типа упал panic или нет, но это же п****ц какой-то для такой тривиальной задачи.
Ну или подключать всякие mq очереди, но опять же, это по сути костыль.
Раньше поглядывал на go, но теперь точно не буду- это слишком жесткое ограничение на уровне языка. Интересно, как try catch в rust выглядит.
sicikh
13.01.2023 23:43Вся шутка в том, что это был Rust, а обработка ошибок в Go мне самому не нравится :) и try catch в Rust нет, вообще никакого
hrls
13.01.2023 23:48+2А for у вас по чем, коллекция интерфейсов? Ну в расте будет коллекция Box<dyn SomeTrait>, где у SomeTrait есть функция опроса конкретного API, возвращающая Result<T, Err>. Err может быть общий для всех API или уникальный для каждого конкретного.
Почти любой код на исключениях переписывается на Result в более явном виде. А для типов-сумм для объединения исключений уже давно придуманы всякие thiserror и anyhow.
Ну и что тут многие не могут освободиться от try/catch в пользу монадической обработки ошибок или банального Result<T, E>, так это печаль конечно. Ибо это эквивалентные модели control flow при наличии поддержки языком программирования соответствующих операторов.
0xd34df00d
13.01.2023 20:41Меня интересует случай, когда ошибка случается, то есть та, которую не предвидели.
В нормальных языках (и нет, хаскель недостаточно нормальный) по индукции вам известны все ошибки рекурсивно.
anone18236
13.01.2023 20:51В third-party api в ответе тип поля поменяли с типа Long на тип String. Вместо циферок теперь буквочки. Как это станет известно?
У вас есть в модели nonnull поле. Такое же было в базе данных, но джун убрал это ограничение, и теперь часть данных не может смапится из базы в модель. Как это станет известно?
Я думаю, что можно найти и другие примеры. Это не может быть известно. И каждый такой чих обрабатывать с моей точки зрения, глупо. Время разработки в космом улетит, если каждую строчку кода или вызов библиотеки, которая может изменится, обкладывать if-ами на все случаи жизни.
0xd34df00d
13.01.2023 21:03+1В third-party api в ответе тип поля поменяли с типа Long на тип String. Вместо циферок теперь буквочки. Как это станет известно?
А вам важно,
Longтам илиString, или вы в прямом смысле перекладываете жсоны?Если важно, то у вас ответ парсится в
data Response = Response { theField :: Long , ... }и функция парсинга имеет тип, упрощая,
parse :: FromJSON a => String -> Either ParseErorr aРаньше вы получали
a, теперь будете получатьParseError.Если неважно, то вы пишете
theField :: Value, гдеValue— это что угодно.Такое же было в базе данных, но джун убрал это ограничение, и теперь часть данных не может смапится из базы в модель. Как это станет известно?
Аналогично.
И каждый такой чих обрабатывать с моей точки зрения, глупо.
Эта ерунда — на границе с внешним миром. Вам там всё равно придётся проверять и обрабатывать кучу вещей, вроде 500-ой ошибки от сервера или лоад балансера, разрыва соединения с БД, по иным причинам несовместимой схемы, и так далее.
Время разработки в космом улетит, если каждую строчку кода или вызов библиотеки, которая может изменится, обкладывать if-ами на все случаи жизни.
Зачем? Вы просто заворачиваетесь в монаду и пишете код так, будто у вас везде один сплошной happy path. Никаких if'ов.
anone18236
13.01.2023 21:30Обычно такие штуки делаете не вы сами, а библиотеки. Что делать в случае, если библиотеки кидает panic при таких ошибках? Свои писать?
Эта ерунда — на границе с внешним миром. Вам там всё равно придётся проверять и обрабатывать кучу вещей, вроде 500-ой ошибки от сервера или лоад балансера, разрыва соединения с БД, по иным причинам несовместимой схемы, и так далее.
Это ерудна кратно увеличивает время разработки. В десятки раз. Только что ради прикола посмотрел что go выдает в делении на ноль
panic: runtime error: integer divide by zeroВы предлагаете при каждой операции деления в проекте проверять, не является ли делитель нулем? Вы предлагаете каждый такой похожий случай (который может вызвать panic) обрабатывать?
0xd34df00d
13.01.2023 21:36+2Обычно такие штуки делаете не вы сами, а библиотеки. Что делать в случае, если библиотеки кидает panic при таких ошибках? Свои писать?
Да, выкидывать, и в языке с нормальными выразительными средствами такая библиотека просто никогда не наберёт популярность. Ошибка парсинга жсона не должна давать panic просто никогда.
Это ерудна кратно увеличивает время разработки. В десятки раз.
Нет. Ну, я разрабатываю вещи в таком стиле (хотя у меня сильно меньше площадь общения с внешним миром, но, вероятно, чуть более нетривиальная логика) — это на самом деле даже помогает.
Вы предлагаете при каждой операции деления в проекте проверять, не является ли делитель нулем? Вы предлагаете каждый такой похожий случай (который может вызвать panic) обрабатывать?
Предлагаю таскать доказательство того, что делитель не будет нулём. Это не так сложно, как вы думаете.
anone18236
13.01.2023 21:46Ну, это все частные примеры- сложно подобрать прям реалистичный. Глобально меня интересует ситуация, когда ошибка уже допущена в коде. Попробую еще пример- джун допустил деление на ноль, на ревью пропустили, тесты прошли, код на проде.
Мой основной вопрос в том, что panic в go, как я понимаю, никак не хендлится- try catch отсутствуют, и вслучае чего, если это произошло в главном потоке- всё, полная остановка приложения. Это так?
0xd34df00d
13.01.2023 21:54Глобально меня интересует ситуация, когда ошибка уже допущена в коде.
Исправили, добавили нужные условия в типы, компилятор сказал, что транзитивно нуждается в исправлении.
Попробую еще пример- джун допустил деление на ноль, на ревью пропустили, тесты прошли, код на проде.
Джун написал свою функцию деления? Зачем, чем его стандартная не устроила?
А если он использовал стандартную, то компилятор от него потребовал это доказательство.
Мой основной вопрос в том, что panic в go, как я понимаю, никак не хендлится- try catch отсутствуют, и вслучае чего, если это произошло в главном потоке- всё, полная остановка приложения. Это так?
Про go я знаю слишком мало, чтобы ответить (но достаточно, чтобы не хотеть на нём писать).
anone18236
13.01.2023 22:09Джун написал свою функцию деления? Зачем, чем его стандартная не устроила?
Ох и любите вы до примеров доколупаться. Я имел ввиду что он написал что-то вида
package main import "fmt" func main() { var b, c int = 1, 0 fmt.Println(b / c) }Но уже не важно, я гугланул ответ. Есть способ, но как вы и писали, это не в стиле го. В стиле го пытаться проверить переменные перед операцией.
но достаточно, чтобы не хотеть на нём писать
Я уже тоже, спасибо.
0xd34df00d
13.01.2023 22:24Ох и любите вы до примеров доколупаться.
Они хорошо иллюстрируют общий принцип.
Если у вас в языке операция деления требует доказательства, что делитель не нулевой, то джуну просто не получится разделить на ноль.
Я имел ввиду что он написал что-то вида
Ну это го опять, а я не про го говорил.
anone18236
13.01.2023 22:31Если у вас в языке операция деления требует доказательства, что делитель не нулевой, то джуну просто не получится разделить на ноль.
Я понял, не сразу, но теперь понял :)
Любопытно, а есть такие сейчас языки, входящие в топ 10 веб разработки? Или вообще в принципе?
0xd34df00d
13.01.2023 23:07В топ-10 точно ничего не входит. Так-то в принципе есть та же уже упомянутая здесь агда.
AMDmi3
13.01.2023 18:11Как исключения вам помогут? Максимум у вас код в проде упадет где-то, вы это залогируете из эксепшена, и потом в этом месте добавите логику для фикса бага. Но данные уже не вернуть.
В go/rust вы сразу знаете все места где у вас упадет код, и в зависимости от контекста и важности функции, сразу можете корректно обработать этот случай.
Вообще-то исключения и коды ошибок функционально эквивалентны - всё что можно сделать одним инструментом можно сделать другим. Разница только в синтаксисе и, естественно, реализации. А синтаксис у исключений лучше по той простой причине что они прокидываются выше по стеку вызовов неявно. Дело в том что мест в коде которые могут завершиться неуспехом много, а мест где по этому поводу можно предпринять какие-то осмысленные действия - мало, поэтому в подавляющем большинстве мест обработки ошибок они просто прикидываются выше. Делать это явно - неблагодарная рутинная работа, и в результате получается раздутый код в котором за обработкой ошибок не видно реальной логики. Выше есть замечательный пример из ядра, он на четверть состоит из обработки ошибок. В rust эту проблему нивелировали до предела позволив прокидывать ошибки одним
!, но по мне так даже это слишком много - визуальный шум и необходимость низачем держать в голове вызовы которые могут вернуть ошибку никуда не исчезли.Пример - загрузка файла в каком-нибудь офисе. Нужно открыть собственно файл, прочитать, раз'zip'овать, распарсить xml, переложить во внутреннее представление, при этом только в парсинге xml может быть куча разных типов ошибок. Но сделать мы с этим ничего не можем - файл в любом случае битый. Структура кода будет одна - последовательность вызовов реализующая шаги загрузки, и обработка ошибки в одном месте где мы просто говорим "не шмогла". При желании обрабатываем конкретные типы ошибок с дополнительной информацией и говорим "не шмогла потому что в foo.xml не закрыт тэг <foo> в строке 79". Так вот код загрузки может быть либо кодом загрузки, либо кодом загрузки перемешанным с прокидыванием ошибок. Лучше однозначно первое.
xenon
14.01.2023 01:17+1Если вы пишите что-то серьезное
А если нет? Не всегда пишется код для медицинского аппарата, самолета или атомной станции. Иногда пишется код заказа пиццы или даже вот такси или покупку билета. Получить правильное решение через три года или почти правильное через месяц? Часто второй вариант лучше, потому что через два месяца рынок займет конкурент.
Эксепшн - отличная штука, это готовый код по умолчанию, который роняет приложение (ну или можно его (необработанное кодом на песте исключение) поймать и иначе обработать). Очень часто это вполне неплохое решение для непредсказуемой редкой проблемы. Признаюсь, у меня есть один код, который иногда ловит странные эксепшны по разным редким сетевым проблемам, и тупо перезапускается. Некрасиво может? Да и ладно. Но со своей задачей он справляется не хуже того кода, который бы все эксепшны в каждой строчек проверял.
BugM
14.01.2023 01:25Для разных проблем нужны разные решения.
Задача аналогична ваше: взять пачку данных из сети (допустим Кафка) и переложить в три другие БД (допустим постгря, http сервис и другая Кафка). Перекладывать надо exactly once, дедупликатор потом не поставить. И тут начинается обмазывание всяким и кучи обработчиков всего. И гарантии везде в коде.
xenon
14.01.2023 02:13Ну если вы по условиям задачи выбрали, что все ошибки надо учитывать и тщательно обрабатывать - ну ок. А чем гошный подход (через data, err := ...) в этом случае легче, чем через эксепшны?
Мне кажется, вы выбрали сложную задачу, ну ее и так решать сложно и сяк - тоже сложно.
BugM
14.01.2023 02:26Это просто демонстрация когда исключения как они есть тоже не очень.
В go худший вариант из возможных, да. Код замусоривается, понять что вот тут оно важно а тут бойлерплейт почти невозможно.
T968
13.01.2023 13:18+1Про goto - прошлось как-то изучать коды FreeBSD, и сразу вспомнил анекдот
"Вовочка,заглянув через замочную скважину в спальню родителей, заметил - И эти люди запрещают мне ковырять в носу"
Так что если противно использовать goto, то выключайте все свои Маки, не пишите электронную почту и не ходите в Инет ))
vadimr
13.01.2023 14:11+2Маркс писал об отчуждении от результатов труда в экономическом смысле. Технически такое отчуждение выполнялось задолго до возникновения капитализма, когда, например, соборы строились по нескольку столетий (сейчас, кстати, такие длительные проекты вновь стали невозможными, уже по экономическим причинам).
tba
13.01.2023 14:28+3вроде бы неглупый человек ляпнул в публичном пространстве совершенно необоснованное суждение "о вредности оператора
goto"Это не так. Вот что писал сам Dijkstra в 2001 :
In 1968, the Comminucations of the ACM published a text of mine under the title "The goto statement considered harmful" which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title...
But what had happened? I had submitted a paper under the title "A case against the goto statement", which in order to speed up its publication, the editor had changed into a "Letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth!
Dijkstra выдвигал аргумент против "unbridled use of goto". Но в истории остался заголовок.ednersky Автор
13.01.2023 14:31+1я знал что вам понравится :)
tba
13.01.2023 15:01+1Я Вас поддерживаю. Против использования goto ничего не имею - в правильном месте и в правильном контексте сильно улучшает читаемость кода. Главное - понимать где он этот правильный контекст и иметь чувство меры.
За Dijkstra стало обидно.ednersky Автор
13.01.2023 15:29Вполне возможно, что взглянув на последующую вакханалию, Дейкстра признал бы сказанное ошибкой, но, увы, что бы он ни имел ввиду, а случилось именно то, что случилось.
tba
13.01.2023 15:32Как он мог признать ошибкой то чего не говорил? Это из разряда "ты уже перестала пить коньяк по утрам?"
ednersky Автор
13.01.2023 15:38-2именно его статья родила что родила
даже если он имел ввиду другое, всё равно, это его ошибка.
Ztare
13.01.2023 15:53+1Может дело не в том что Дейкстра имел ввиду не это? Может разработчики обратили внимание на эту проблему, подумали и решили пойти дальше и глубже, а ошибка подтверждать такие решение его словами? Сейчас goto массово не применяется по многим причинам, но жалоб что-то не особо много.
И при этом замены только развиваются: из последнего что видел и может заменять goto - это возможность писать тело лямбд снаружи от вызова функции в kotlin, прям кайф. Понятно что это не прям для этого сделано, но как способ организации потока управления прям мощьednersky Автор
13.01.2023 15:56но жалоб что-то не особо много.
странно бы было слышать жалобы из гетто, согласитесь?
Вряд ли их даже кто-нибудь запишет
Ztare
13.01.2023 17:03Нет не соглашусь. Тут нет гетто - при желании получить этот оператор можно так или иначе. Это прям толсто - теория заговора во всей красе.
Высказать свое мнение может каждый, прилагая аргументы. Текущее положение с оператором goto это результат развития понимания программирования, инструментов и индустрии.
Аргумент в статье незначителен - не опровергает причин отказа, аргументы приведенные в коментариях слабые. Сильных вы не приводитеednersky Автор
13.01.2023 17:05Высказать свое мнение может каждый, прилагая аргументы
но решение примет один - представитель крупной международной корпорации
WraithOW
13.01.2023 17:18+1Вас как будто заставляют Go использовать. Языков вагон, не нравится Go - используйте раст, джаву, плюсы, kphp, c#, erlang, вариантов вагон.
ednersky Автор
13.01.2023 17:26Вас как будто заставляют Go использовать
Именно заставляют. Сравните:
То, что принуждение экономическое, то, что отсутствует надсмотрщик с кнутом, не отменяет факт принуждения, правда?
WraithOW
13.01.2023 17:29+2Я сразу скажу, что у вас ошибка в методологии - многие компании не публикуют зп. Сравнивать деньги по hh в IT плохая идея.
Алсо за те же деньги можно писать на джаве, котлине и шарпе, где исключения есть.
ednersky Автор
13.01.2023 17:33Алсо за те же деньги можно писать на джаве, котлине и шарпе, где исключения есть.
раб свободен поесть перед работой на плантации, либо после.
вывод - рабы - свободны и разговоры об их освобождении - мишура.
как-то так
WraithOW
13.01.2023 17:37+3По существу-то есть что ответить? Кто вас заставляет писать на Go? Аргумент про деньги опровержен, что еще осталось?
Вы как человек, который на приеме у хирурга с лампочкой во рту жалуется на диктатуру производителей цоколей E24.
ednersky Автор
13.01.2023 17:40Аргумент про деньги опровержен, что еще осталось?
отвергнут != опровергнут
WraithOW
13.01.2023 17:50+3Бремя доказательства лежит на утверждающем, так-то. Предоставить нормальные данные - ваша отвеcтвенность
Ну да ладно, на дворе пятница, не время говниться. Давайте я пойду вам навстречу и краткости ради соглашусь, что hh - хороший источник данных:
581 вакансия «программист Go»
от 275 000 руб. 69Работа программистом Java в Москве, 1 865 вакансий
от 285 000 руб. 118Работа программистом C# в Москве, 917 вакансий
от 250 000 руб. 94500 вакансий «программист kotlin»
от 285 000 руб. 45Покажите на кукле, где вас экономически принуждают.
ednersky Автор
13.01.2023 17:53Бремя доказательства лежит на утверждающем
я считаю что привёл достаточно доказательств: в 10 раз различное количество предложений на рынке труда - вполне качественная характеристика
WraithOW
13.01.2023 18:10+3Как я уже сказал, данные с HH нерепрезентативны, потому что многие крупные компании не показывают зп в вакансии. Вот, к примеру, ВК: https://hh.ru/employer/15478 172 программистские вакансии, ни в одной нет ЗП. Хотя платят там, поверьте, хорошо.
Если перейти во вашей ссылке про GO и выставить там вилку от 455 тысяч, то среди 14 вакансий будут: Highload PHP Developer (200-500), Flutter разработчик (400-700), Senior Backend Engineer (Kotlin/C++/Python) (380+) и 2 Devops-вакансии. Если треть данных - мусор, то я хз, о чем тут рассуждать.
Даже в данных с HH, у Go вполне себе есть альтернативы, как видно из приведенных мной цифр. Есть более популярные языки, за которые платят не меньше.
Итого исходный тезис
Именно заставляют [использовать Go
очевидно не подтвержден, и даже почти опровергнут
ednersky Автор
13.01.2023 18:13но количество вакансий - вторая цифра
многие компании не показывают бюджет, а многие показывают
WraithOW
13.01.2023 18:18+2Вы умеете читать, восхитительно. Давайте теперь проверим ваши способности к математике.
581 вакансия «программист Go»
от 275 000 руб. 69Работа программистом C# в Москве, 917 вакансий
от 250 000 руб. 94Что больше:
581 или 917?
69 или 94?
Не топопитесь, подумайте.
ednersky Автор
14.01.2023 16:56обошёл квартиру, померил температуры батарей отопления.
65 градусов и 54.подумайте над цифрами, не торопитесь отаечать
WraithOW
14.01.2023 17:01+2По существу ответить нечего, что и требовалось доказать. Как вы там сказали? "Паяц"?
ednersky Автор
14.01.2023 18:17температура в трубах отопления имеет такой же статус как Java и С# по отношению к Go и Perl
WraithOW
13.01.2023 18:33+1Так в чём рабство-то? В том, что вы можете выбирать, где работать, кем, и за какие деньги? Аргументы какие-то будут, или одни лозунги?
ednersky Автор
14.01.2023 16:58ещё разок: замена методов принуждения с насилия на экономические ситуацию меняет крайне слабо
WraithOW
14.01.2023 17:03Ещё разок - где принуждение? Кто вас заставляет писать на Go, если есть вакансии на других языках за те же деньги? Напомню исходный тезис, а то у вас вижу память хуже чем у золотой рыбки
но решение примет один - представитель крупной международной корпорации
0xd34df00d
13.01.2023 20:45+2Можно даже писать за совершенно бешеные деньги на плюсах. Там и исключения, и коды ошибок, и goto, и можно даже те же монады (линейное их подмножество) навернуть, если хорошенько отабьюзить
co_await. И полная свобода творчества, проезда по памяти, выстрела в ноги,reinterpret_cast. Главное — оптимизации не забыть выключить, а то паршивец-компилятор начнёт уже сам свою свободу демонстрировать.
vitaly_il1
13.01.2023 14:37+2Однозначно - отменить все языки кроме ассемблера! А за фреймворки расстреливать!
А заодно и автоматические коробки передач и автоматику в автомобилях отменить - они лишают водителя творчества.ednersky Автор
13.01.2023 14:40Однозначно - отменить все языки кроме ассемблера!
отказ от исключений - шаг назад, к ассемблеру
отказ от динамического вычисления типов (перекладывание этой проблемы на плечи программиста) - шаг назад, к ассемблеру
Очень рад, что Вы имеете мнение приблизительно коррелирующее с моим: всё это - деструктивные шаги.
Cerberuser
13.01.2023 16:51отказ от динамического вычисления типов (перекладывание этой проблемы на плечи программиста)
Вы специально построили фразу так, как будто это одно и то же, несмотря на то, что второе - даже не строгое подмножество первого, а вообще пересекается только частично?
ednersky Автор
13.01.2023 16:54-1нет, это именно такое моё мнение.
я считаю что второе - строгое подможество первого.Cerberuser
14.01.2023 09:50То есть, когда я на том же Rust большую часть типов оставляю выводиться компилятором и не прописываю сам - это динамическое вычисление?
vkni
13.01.2023 20:31+3отказ от динамического вычисления типов (перекладывание этой проблемы на плечи программиста) - шаг назад, к ассемблеру
Так вот динамическая типизация по сравнению с нормальной статической (Хиндли-Милнер и т.д.) — это и есть шаг назад. Питон обычно сложнее Хаскеля, т.к. в программе на Хаскеле вам IDE рассказывает, какой у вас там тип, а в Питоне приходится самому вычислять.
Ivan22
13.01.2023 14:50+3ассемблер - это блаж, абстракция поверху трушного бинарного кода
0xd34df00d
13.01.2023 20:50+1Бинарный код — блажь поверх трушной RISC-машины внутри всё ещё более распространённых на десктопах x86. Только микрокод, только хардкор!
johnfound
13.01.2023 15:03+6— Потому что эта функция запускается один раз в сутки. Даже если время её исполнения будет равно 600 секундам, то это всё равно будет устраивать абсолютно всех пользователей.
А потом приходит кто-то и именно эту функцию вызывает прямо во внутреннем цикле всего-то 1000 раз и все виснет конкретно на 6 секунд. Из за этого (потому что тикет не написали и никто уже не помнит в чем суть) запускают еще 10 серверов – и хорошо, если функция масштабируется хорошо, а вполне возможно, что и нет – ведь эта функция запускается раз в сутки, зачем делать ее масштабируемой.
И это не гипотеза. Я такое видел тысячу раз. Поэтому, если можно сделать за 600мкс, а сделали за 6мс, то это однозначно техдолг. Возвращать его или не возвращать, это время покажет. А тикет должен быть. Пусть постоит есть-пить не хочет.
ednersky Автор
13.01.2023 15:11+2Практически любому примеру противопоставляется контр-пример.
Только вероятность подобного близка к нулюBugM
14.01.2023 00:30+3Вы наверно из тех кто думает в что корзине товаров не бывает тысяч единиц товара и можно не париться с обработкой того что там? Квадрат, так квадрат. На типичной корзине в 10 единиц все равно никто не заметит.
Или из тех кто считает что воон в тот массивчик вам никогда не передадут миллионов 100 значений? И можно его оптом сгрузить в БД, например.
tba
13.01.2023 15:29+8Техдолгом это станет тогда когда функцию начнут запускать 1000 раз. И даже не тогда, а когда раздражение/потери превысят уровень оценки рисков того, что "оптимизация" а) сожрет кучу времени разработчиков б) будет работать неправильно и кто-то попадет на деньги. Тоже такое "видел тысячу раз"
johnfound
13.01.2023 15:47+2Не согласен. Техдолгом это становится сразу. Но не все долги надо отдавать. Но дело в том, что надо возвращать или нет станет понятным намного позже. И поэтому весь техдолг надо документировать. Чтобы не забылся.
А автор выступил за то чтобы об этом техдолге просто забыли (скрыли?). Наверное чтобы не портить статистику. Самообман чистой воды.
kazimir17
13.01.2023 17:06+2Это странно честно говоря, в любом проекте 99.9% функций можно еще ускороить, значит ли это на все это надо оформлять как тех долг?
johnfound
13.01.2023 18:02-1Если знаете как сделать – примерно поменять алгоритм, то да, надо оформлять. Если сознательно сделали медленнее, чем можно было (из за разных соображений) – то тоже да. А если не знаете как сделать быстрее, то, конечно не надо ничего писать. Ну или завести один тикет: "Помни, что весь этот код можно улучшить."
Rukis
14.01.2023 13:17+2При распространенности такой практики в проекте заводить этот тикет можно сразу в dev/null ибо никто о нём более никогда не вспомнит. Уж лучше коммент чиркануть к методу о возможности его оптимизации и примечание в доке о сценарии использования, тогда хотя бы есть шанс что на это обратят внимание, когда захотят использовать его не по назначению или таки столкнутся непосредственно с проблемой его быстродействия.
XelaVopelk
13.01.2023 21:17"Техдолгом это становится сразу. " сразу после чего? после коммита фичи?
PS Если долг не надо возвращать, то почему это долг ибо долг сам по себе есть обязательство возврата? :)johnfound
13.01.2023 21:51Ну, вы забыли что долг начинается сразу как только его возмем. А возвращать надо через какое-то время (поэтому и долг). А срок может быть разным. И еще долг можно списать. Так что нет противоречия. Техдолг становится техдолгом как только коммитим код с компромиссами.
XelaVopelk
13.01.2023 22:03+2Ещё раз почитайте дефиницию: если что-то не надо возвращать, это не долг.
В любом коде есть компромиссы: там мы приносим в жертву читабельности производительность, а там наоборот (за исключением откровенных тривиальностей) Любое техническое решение есть компромисс.BugM
14.01.2023 00:37+1И во всех случаях хорошие разработчики это документируют.
Сурово оптимизированный код где читабельность принесена в жертву обвешивается огромными комментариями. Иногда даже со ссылками на научные работы. Почему так, зачем это тут вообще и как это работает.
Явно неоптимальный код требует заведения тикета с текстом о том как его оптимизировать.
И можно жить. Следующее поколение разработки работающее с вашим кодом вам спасибо скажет.
Ivan22
15.01.2023 00:14+1ну долг был, был. А потом весь модуль закрыли, вместе с долгами. Так что бывает так что долги можно и списать
nronnie
13.01.2023 16:03+5Поэтому, если можно сделать за 600мкс, а сделали за 6мс, то это однозначно техдолг.
Есть такая вещь, как "nonfunctional requirements". Если по ним 600 мкс достаточно, значит их достаточно. Если они (requirements) поменялись, и стало недостаточно, то только тогда и надо переделывать.
wzei
13.01.2023 18:33+1Является ли код техдолгом или нет определяется тем, соответствует ли он требованиям или нет, отражает ли он ту реальность, под которую его собираются использовать. И если отражает, то это не тех долг. Если практика применения кода измениась так, что код не отображает ее, то это уже тех долг. И это только опытом познается. Это частный случай философского вопроса об истинном и ложном знании, применительно к разработке.
rezedent12
13.01.2023 15:13+6Это процесс называется "пролетаризация", ранее ему подверглась интеллигенция типа врачей, учителей и инженеров.
ilnarb
13.01.2023 15:39Хочется лишь сказать: всё циклично!
Придет время, когда откажутся от избыточной микросервисности и вернутся к классике "Premature optimization is the root of all evil".
По этой логике следовало сначала выпустить первую версию, снять стату, может даже не пришлось бы сервис развивать, а закрыли бы за ненадобностью. Неужели нельзя было мертики снимать Яндекс.Метрикой?
IRS
13.01.2023 15:48+3Какой толстый троллинг всех и вся. Мне понравилось.
А что, при правильно выстроенном монолите не происходит отчуждения результатов труда? Так то правда в ней есть — одних макак легко заменить на других — один хрен так же неэффективно будут ковырять громоздкий сервисмеш.
но ви таки считаете, что с монолитом такое нереализуемо? Вы несколько ошибаетесь. И наивно думать, что унеся унылый монолит домой и будучи способным его запустить — от этого так сильно пострадает работодатель. Голая ИС без бизнеса и кучи людей, которую они наполняют данными и кучи неайтишных спецов — ничего не стоит сама по себе.
И да, зачем по дедку кену томпсону проехались? У него была цель простой как молотое понятный язык запилить для айти-макак. Он ее выполнил.
safinaskar
13.01.2023 15:51+4Автор, расскажу вам про один язык программирования, а точнее, про семейство языков, я думаю, вам понравится. Это Lisp. Из его вариантов я имел дело с Scheme. Динамически типизированный. И исключения имеются (по крайней мере в Scheme). Всё, как вы любите.
А самое главное, при помощи макросов в этом языке можно сотворить совершенно что угодно. Любую повторяющийся код можно выделить в отдельную абстракцию. Don't repeat yourself, возведённый в абсолют. Код на Lisp получается предельно сжатым, любую ошибку нужно будет исправлять только в одном месте. С помощью макросов вы по сути создаёте свой язык. И препроцессоры для добавления недостающих фич можно легко реализовать на самом Lisp с помощью этих макросов.
Программирование на Lisp происходит так: программист начинает писать программу, по мере надобности с помощью макросов добавляет нужные ему фичи (фичи самого языка). В результате пишет он не на данном варианте Lisp, а на своём языке. Полная свобода для творчества.
Продолжение этих мыслей можете найти тут: http://paulgraham.com/avg.html (есть такой русский перевод: https://nestor.minsk.by/sr/2003/07/30710.html , за качество перевода не ручаюсь).
А в чём же подвох? Подвох в том, что поскольку каждый пишет на своём языке, одному программисту сложно въехать в код, написанный другим. Из-за чрезмерной вседозволенности языка язык абсолютно неприступен для линтеров. И IDE тут малополезны. Словом, это абсолютный ад для бизнеса. Полный антипод микросервисного капиталистического рая.
Так что попробуйте, думаю, вам понравится.
Теперь по существу. С вашей статьёй не согласен. Согласен со многими вашими критиками-комментаторами. Сам я пробовал Scheme. Язык красивый, но использовать не буду, т. к. люблю статическую типизацию.
Добавлю, что в этом моём комменте нет шуток. Сарказм, может, есть, но шуток нет, т. е. каждое предложение нужно понимать буквально, а не наоборот
ednersky Автор
13.01.2023 15:55Так что попробуйте, думаю, вам понравится.
Дык я пользуюсь, мне нравится :)
Другой вопрос, что я не совсем с вами согласен. Проблема LISP всё-таки в ориентации на функциональное программирование. Это не техническая проблема, а снова - иного характера.
Приходится чуток вывернуть мозги по-иному, чтобы на нём писать, это выворачивание - безусловно полезно, но не нравится тем, кому мозги напрягать не хочется.
Как-то такvkni
13.01.2023 20:29+2Есть чудесная стать про «программистов на LISP» — https://www.marktarver.com/bipolar.html
Она примерно про то, как отчуждение их перемалывает.
CodeRush
14.01.2023 01:26+3Статья действительно отличная, только вот перемалывает их не отчуждение, на мой взгляд, а сочетание особенностей характера с неумением с этими особенностями жить.
У меня тоже такая вот биполярочка, и мне тоже бывает невыносимо скучно порой заниматься тем, что от меня хочет работодатель, и я даже брал от этого рутинного строительства очередного шестого по счету секуребута годовой неоплачиваемый отпуск, чтобы справиться с этой скукой, депрессией, демотивацией от бессмысленности сущего, и прочим подобным. Года вполне хватило, чтобы отрефлексировать и пояснить самому себе, зачем оно, вот это все, и почему устроено именно так.
Корпорация отчуждает результаты твоего труда сразу и в полном объеме, потому что именно за этот труд и его результаты корпорасты деньги и платят. Русское выражение "заработная плата", т.е. "плата за работу" проигрывает в выразительном смысле английскому compensation. Работодатель буквально компенсирует деньгами, страховками, фитнес-центрами, и прочим остальным тот факт, что теперь он - обладатель прав на результаты твоего труда, твои идеи, твой код, твои действия и бездействия. И ты их добровольно передал в результате относительно честной сделки (насколько она может быть честной при большой разнице возможностей, понятно), от которой выгоду получают оба ее участника - корпорация монетизирует твои идеи, код и т.п., а ты при этом освобождаешься от необходимости заниматься этой монетизацией самостоятельно.
Более того, иногда мотивы у корпорации могут быть совершенно отличными от банального "вон чувак умеет программировать, давайте купим его время и мозги, чтобы он нам напрограммировал всякого". Там может быть и "давайте наймем чувака раньше конкурентов, чтобы он им не принес никакой пользы", "давайте наймем чувака, чтобы он перестал нас шельмовать в медиа за косяки, которые он нашел, а мы не исправляем", и т.п.
У меня тут вокруг заметное количество очень сильных, иногда буквально гениальных людей, и почти десяток лет работы с ними научили меня всякому, в том числе тому, что процессы, правила, линтеры и запреты на использование языковых конструкций, которые слишком часто используются неверно даже гениальными людьми, потому что они в первую очередь все таки люди - они не просто необходимы, они неизбежны, также, как и разделение труда и специализаций. Нет, никто не предлагает делить до такой степени, что левую резьбу крутит инженер-леворезьбовик, а правую - инженер-праворезьбовик, но вы буквально упретесь в когнитивные возможности человеческого мозга "понимать все" и "видеть всю картину" уже на уровне RTL, не имея еще никакого ПО вообще.
Настоящего "фуллстека" буквально не бывает, потому что сложность у современных вычислительных систем - абсолютно запредельная, глубокоуважаемый @YuriPanchul не даст соврать. Поэтому договариваемся на берегу про словарь и умолчания, делим обязанности, и жрем этого слона по частям, больше никак.
0xd34df00d
13.01.2023 20:52+3Проблема LISP всё-таки в ориентации на функциональное программирование.
Ничё страшного, у лисперов есть call/cc — это как goto, только можно ещё лапшеобразнее.
kazimir17
13.01.2023 16:33Не знаю как в Яндексе, а на моем текущем месте работы (один крупный банк в желтых тонах) идею сделать что-то за неделю вместо 2 лет и получить результат приняли бы на ура. Хотя у нас тут микросервисы во все поля.
wzei
13.01.2023 16:36+3Может быть, кому-то будет интересным, но в начале 20 века, творил поистине великий философ и учёный - А.Богданов. Он, в частности, предложил ввести понятие "фулстек-учёного" и добавить науку, объединяющую все прочие.
...
Основная идея Тектологии состоит в том, чтобы выявлять общие закономерности в совершенно разных науках: общественных и естественных, химии и истории итп, сводя подходы к единообразным...
Эта наука давным давно существует. Называется она философия. Причем в полном виде она была открыта тем же Марксом, на которого вы так любезно ссылаетесь.
P.S: Понимаю, что у позитивистов и некоторых другиих существует свое мнение, но из контекста очевидо, что их подходами я не могу согласиться.ednersky Автор
13.01.2023 16:37сам Богданов противопоставлял философию и тектологию
wzei
13.01.2023 17:04+2Говорил, что занимается не философией... Но при этом взял и по сути переименовал основные философские категории на свой лад, назвав это всё тектологией. Ну и приправил доброй порцией позитивизма. То есть пошел в бок от магистральной линии философии, став просто очередным "некласическим философом".
Зачем нужна такая теория, когда уже придумали диамат (который и скрывается у меня в тексте под именем "наука философия")?
Dgolubetd
13.01.2023 16:39+8Вот что получается, если писать статьи в 05:56..
Честно сказать, не пойму реально ли стеб или автор серьезно, поэтому буду отвечать как на серьезную статью.
Софт - он разный. Требуемые характеристики как к готовой программе, так и к процессу разработки всегда будут варьироваться. Естественно нельзя равнозначно рассматривать какой-то скрипт-счетчик на веб сайте и программу управляющую турбинами на АЭС.
Но все-таки, есть тенденция, что мы больше взаимодействуем и работаем вместе. Появляется больше крупных компаний с большими командами, больше open-source проектов, много сторонних зависимостей. В таких условиях становится важнее вырабатывать способы взаимодействия и технологии, упрощающие чтение и понимание кода, его рефакторинг, снижающие вероятность поломок при апгрейде и т.д.
Про миросервисы
Вы считаете, что микросервисы навязывает бизнес, чтобы разработчики не знали всей кухни. А может быть сами разработчики не хотят её знать? Как вы себе представляете онбоардинг нового разработчика в Яндекс, которому нужно разобраться во всём написанном тысячами людей в течение многих лет? Когда такой сотрудник начнет работать, после всего лишь пары лет введения в курс дел?
С организационной стороны они позволяют командам работать намного быстрее. Да, винтики, но так и должно быть в крупных компаниях.
А технически микросервисы распределяют нагрузку. Для них не нужен мега-сервер с ТБ оперативной памяти и сотнями ядер. В добавок можно отрегулировать сколько ресурсов выделять на тот или иной сервис, на сколько его параллелить. Падение микросервиса может сломать лишь часть приложения, а упавший монолит - полный даунтайм всего.
Да, у них много накладных расходов, но в крупных компаниях они оправданы.
Про типизацию
Автор когда-нибудь пробовал разобраться в большом объеме JS кода? Когда пытаешься понять что делает эта функция foo, у которой на входе нечто и на выходе нечто, а в своем коде она вызывает другие такие же функции, работающие с нечто.
Или обновить зависимость в python проекте, вносящую breaking change. Когда баги после такого обновления продолжают всплывать спустя месяц.
Всё это митигируется статической типизацией.
Про goto
Человеческий мозг способен воспринимать одновременно лишь ограниченный контекст. Поэтому мы придумали вначале разбивать программы на процедуры, потом на классы, потом появилось функциональное программирование с чистыми функциями. Всё для того, чтобы можно было посмотреть на кусок кода и понять, что он делает, без необходимости внимательно изучать остальной код. И это действительно работает.
Оператор goto нарушает этот принцип, он заставляет читающего код человека разбираться во всем окружающем коде, куда этот goto переходит, скрывая вместе с этим семантику: то ли это цикл делается, то ли быстрый переход к освобождению ресурсов - на месте не понятно.
Помимо читаемости есть технические аспекты, освобождения ресурсов, валидации возвращаемого функцией типа и тд.
Wrapping up
Получился длинный коммент..
Вообщем, я надеюсь, что все-таки это был стёб (пусть я тогда и напрасно писал всё это).
Но если нет, то, как говорила одна личность: "УЧИТЬСЯ, УЧИТЬСЯ И ЕЩЕ РАЗ УЧИТЬСЯ.."
ednersky Автор
13.01.2023 16:52+2Вы считаете, что микросервисы навязывает бизнес, чтобы разработчики не
знали всей кухни. А может быть сами разработчики не хотят её знать?оба тезиса верны. Второй - потому что среднему человеку проще плыть по течению. Увы.
Как вы себе представляете онбоардинг нового разработчика в Яндекс,
которому нужно разобраться во всём написанном тысячами людей в течение
многих лет?как-то справлялись с онбордингом до этого?
при этом больше задач решали меньшим числом людей
По преждему считаю, что на любой крупный проект достаточно 5 человек (мнение Брукса).
по мере роста проекта из него можно подвыделить второй крупный и получить команду 10 человек.как-то так
Автор когда-нибудь пробовал разобраться в большом объеме JS кода?
Да и в статье я указал, что об этом (возможно) ещё напишу.
Если коротко: тайпскрипт принёс в JS не только типы, но и модифицированный ООП, асинхронщину итп. Да, что-то обратно вмержено уже в сам JS, но на момент создания тайпскрипт всего этого в JS не было. И тайпскрипт стал популярен не по причине типов (среднестатистический проггер на тайпскрипт, тайпы в нём и не использует), а по причине прочих фич
Человеческий мозг способен воспринимать одновременно лишь ограниченный контекст.
согласен, и потому считаю выпил goto вредным: это приводит к большей многословности (или вложенности) кода, там где с goto могла быть лакончиная программа парсера или стейтмашины
IRS
13.01.2023 17:21Не по причине типов а по причине наличия декораторов, позволяющих легче завернуть код внутрь фремворков типа ректакта с ангулятором. Типы не пользуют но линтеры для типобезопасности — да. И да, современным кодерам тяжко без линтеров. Как без няньки же.
vkni
13.01.2023 19:30+2согласен, и потому считаю выпил goto вредным: это приводит к большей многословности (или вложенности) кода, там где с goto могла быть лакончиная программа парсера или стейтмашины
Кмк, вы слишком категоричны тут, коллега. Нам не нужен один язык на всех. Наоборот, вы же сами пропагандируете универсальность программистов, а значит равное владение разными языками. А в разных областях применения должны использоваться разные языки.
Я, как энтузиаст FP, очень люблю статическую типизацию и вывод типов (она позволяет находить логические ошибки прямо глядя на код вот тут сразу — это автоматизация, освобождающая простор для творчества). Однако, я прекрасно понимаю, что в ряде задач эта автоматизация сковывает полёт мысли. То есть, в ряде задач нужно использовать не Питон, а совершенно безбашенный Lisp со вложенными квазицитированиями (см. мою последнюю публикацию).
Вот та чудесная статья про две культры Плахова (он, конечно С++ник, но в жж он вращался среди функциональщиков тоже) — кмк, реально нужно иметь не две культуры, а спектр. Творчество же разделяется на поиск, фильтрацию и передачу полезного в Культуру. На фазе поиска желательно иметь полёт мысли, на фазе фильтрации-проверки наоборот, желательно сковать себя максимально, чтобы остались лишь верные мысли.
Cerberuser
14.01.2023 09:57(среднестатистический проггер на тайпскрипт, тайпы в нём и не использует)
Использует, почему же. Надо же явно написать any там, где компилятор за тебя уже вывел что-то более ограничивающее.
AYamangulov
13.01.2023 16:46+1На самом деле существует очевидный способ сделать код с goto сравнительно легко читаемым и даже подружить его с линтерами всех мастей. Достаточно в ЯП проапгрейдить goto - а именно, сделать его с индексом, что-нибудь, вроде goto(строка, куда нужно перейти, сгенерированный индекс) и добавить оператор-ловушку, например, назовем его gofrom(строка откуда совершен переход, тот же самый индекс), единственная функция которого - показать, что в это место кода кто-то сделал goto откуда-то именно. И можно даже добавить в IDE средства для автоматического расставления ловушек в места, куда вы сами сделали goto. И все - любые линтеры и IDE смогут это обработать и сделать легко читаемые переходы и даже клики для линков туда-сюда. Внимание, идея зарегистрирована, как торговая марка @goto-gofrom!????
vadimr
13.01.2023 17:19+1Для этого достаточно не использовать одну и ту же метку в нескольких операторах goto.
vkni
13.01.2023 20:16+2-
В статье в этом месте фактическая ошибка — Дейкстра боролся с неограниченным goto, то есть, возможности прыгать куда угодно по тексту программы. Этот goto выпилили, потому, что если вы настолько понимаете, что происходит, пишите на ассемблере. Это даже в С будет дичайшим образом ломать ООО в процессоре и оптимизации компилятора.
Да, основной цикл интерпретатора, видимо, надо писать на ассемблере. Или ассемблеро-подобном языке, не на С. Почему — см. статьи В. Казанцева про pigletvm тут и рассказы автора LuaJIT (если надо, могу найти).
Обычные метки С ломают композиционность структурного программирования. В 80е публиковались статьи по структурному программированию, обосновывающие введение конструкций if/while/do while/continue/break с точки зрения достаточности для моделирования goto и композиционности (т.е. того, что их можно вкладывать друг в друга).
Вот все эти мелочи не умаляют главного посыла статьи, с которым я 146% согласен.
ednersky Автор
13.01.2023 20:19-1фактическая ошибка — Дейкстра боролся с неограниченным goto
но его послание к людям привело к выпилу goto вообще.
именно на его апокриф ссылаясь и его именем этот оператор предавался анафеме.
А так-то, может быть и Иисус Христос тоже "не то имел ввиду", но что есть, то есть :)
vkni
13.01.2023 20:38Абсолютно верно. Я призываю вас поклониться богине Гиене Ги — чётко разделять определённую мысль, выдвинуту вполне умным авторитетным человеком, и социальное движение, ведущее её к абсурду. Фактически религиозный фанатизм — положительные обратные связи, аналогичные капитализму (это же тоже положительная обратная связь: капитал должен возрастать).
То, что классики подразумевали под рационально устроенным обществом, обществом, построенным не хаотично, а по плану — это общество, в котором социальные механизмы, положительные и отрицательные обратные связи контролируются, моделируются, убираются когда они нужны, и когда нет.Наша цель — такое общество. При этом все эти хаки вроде Принципа Питера, бюрократия растёт сама собой, и т.д. должны быть переложены на аппарат Теории игр. А уже после их полного учёта можно будет говорить о построении рационального общества.
Соответственно, коллега, нам нужно очень чётко разделять социальный механизм и случайную затравку, запустившую этот механизм. Затравка нас не интересует! Какая разница, какая именно провокация запустила маховик ПМВ?
-
gatoazul
14.01.2023 14:57Ваша идея давно реализована в языке INTERCAL - 1972 год. Оператор COME FROM. Вы чуть опоздали.
Guid0Fawkes
13.01.2023 16:54+4и заодно припомнить, "что они сотворили с фронтендом"...
Хотелось бы услышать. Вот уж что точно не радует все эти годы, так это именно фронт. Хотя понятно, что это мнение будет в меньшинстве.
А вообще статья понравилась, во многом солидарен с автором. Начиная от Goto и вплоть до его отсылок к Марксу, пусть последний и не популярен в здешних палестинах.
vkni
13.01.2023 19:17Ну как это — не популярен? Судя по моей карме (там почти всё за «политику»), примерно половина за, а половина — против.
gatoazul
14.01.2023 14:59Маркс не может быть популярен у тех, кто и выигрывает от нынешнего положения вещей. А среди программистов таких полно, особенно, кто на западе живет, а не в России. Их легко узнать по пещерному антикоммунизму и вере в чудотворные способности свободного рынка и демократии.
Kanut
14.01.2023 15:11+5Вы конечно извините, но Маркс не может быть популярен у тех кто хоть немного в этом разбирается.
И даже если брать современные левые и/или социальные идеи и движения, то с Марксом они имеют относительно мало общего.
То есть я например даже будучи программистом вполне себе поддерживаю социально-солидарную политику в Германии. Хотя для меня это означает что я плачу больше налогов чем мог бы. Но при этом идеи конкретно Маркса на мой взгляд как минимум устарели. А по хорошему никогда особо хорошими и не были...
gatoazul
14.01.2023 15:14+1С мировым пролетариатом вы тоже делитесь доходами? Ну там разными китайцами на потогонках, с неграми, добывающими редкие металлы.
Kanut
14.01.2023 15:23Во первых да, делюсь. Хотя и не в тех же объёмах.
Кроме того я что-то не припомню чтобы Маркс требовал чтобы одни пролетарии обязательно делились своими доходами с другими пролетариями. Этот аспект его не особо интересовал/волновал.
gatoazul
15.01.2023 12:47С чего вы решили, что вы глобальный пролетарий? Вы живете в ядре мир-системы.
Kanut
15.01.2023 12:51По определению слова "пролетарий", которое кстати использовал и даже пожалуй этаблировал сам Маркс :
Пролетариа́т — социальный класс, для которого работа по найму (продажа собственной рабочей силы) является по существу единственным источником средств к существованию.
И это как раз показывает почему идеи Маркса сейчас не особо актуальны. То есть он не особо заморачивался такими вещами как например "расслоение" внутри самого пролетариата.
gatoazul
15.01.2023 12:50Так у Маркса же были плохие идеи, которые к тому же еще и устарели. Что же вы ссылаетесь на него, оправдывая свое нежелание делиться?
Kanut
15.01.2023 12:53Я не ссылаюсь на него. Я вам указываю почему идеи Маркса в современном мире уже не особо актуальны. И почему само по себе деление на пролетариев и не пролетариев сейчас не особо имеет смысл проводить.
iig
15.01.2023 15:32Ну как же, старинный принцип "разделяй и властвуй". Развесить ярлыки - и давайте, боритесь друг с другом.
SandmanBrest
15.01.2023 03:17А кто это такой вообще: "мировой пролетариат"?
gatoazul
15.01.2023 12:50Пролетариат - это класс, лишенный средств производства. В эпоху глобализации и пролетариат стал глобальным. Именно он и имеется в виду.
iig
15.01.2023 15:36+1У молотобойца средство производства - его кувалда. Не вижу причин, почему бы ему не заработать на собственную личную кувалду и перестать быть пролетарием.
Я уже молчу про всяких реперов или актёров, у которых средство производства неотделимо от их организма, и они зарабатывают так, как не у всякого буржуя получится.
WraithOW
14.01.2023 15:32+1Маркс не может быть популярен у тех, кто и выигрывает от нынешнего положения вещей.
Это предложение очевидно разбивается об ОПа, который имеет зарплату в разы выше средней в стране и как раз выигрывает от текущего положения вещей.
0xd34df00d
14.01.2023 20:02вере в чудотворные способности свободного рынка и демократии.
Считаю, что наиболее эффективное общество — при свободе договора, но совершенно, напрочь не верю в демократический миф (особенно с репрезентативной демократией). Можно диагноз?
Getequ
13.01.2023 17:06+5Бедный человек - борется с линтерами, форматировщиками кода, и прочее.
Интересно что же с ним произошло в момент, когда он узнал о существовании автоматической сборки мусора в виртуальных машинах dotnet, Java etc - Да как же. Это. Возможно! Человеку больше не надо геммороиться с учетом delete на каждый new и прочими утечками памяти? НЕМОЖНО ТАК!
Я разделяю волнения по поводу того что все свихнулись по микросервисам и предают анафеме goto, но зачем впадать в ТАКИЕ крайности?
ednersky Автор
13.01.2023 17:34+12@All:
Заметьте, в комментах много споров на тему исключений, goto, а вот с де-факто утилизированным принципом KISS все получается согласны?
WraithOW
13.01.2023 18:14+4Вы в качестве примера привели одну единственную компанию, которая тупо обросла бюрократическим жиром. Это какбы стандартная проблема роста, которая конкретно к программированию имеет отношение очень опосредованное: люди пытаются управлять сложностью, вводя избыточные регламенты.
Экстраполировать один пример на всю индустрию - ну так себе.
vkni
13.01.2023 18:57146%. Но вот в возражении WraithOW рядом — про бюрократизацию, есть доля истины: отчуждение труда идёт рука об руку с иерархией менеджеров, с КПИ, совершенно несвязанными с целью деятельности, с конкуренцией. Вот эту системную связь было бы неплохо разобрать.
0xd34df00d
13.01.2023 21:14Раз тут об этом пошла такая пьянка — ты Burnham'а читал?
vkni
13.01.2023 21:28Нет!!! Убейте меня, пожалуйста, у меня нет времени, скопилось дофига книг и статей, которые нужно ПРОРАБОТАТЬ, а даже не прочитать! :-)
Я и эту-то статью читать не должен был! :-)
Давай ссылку!0xd34df00d
13.01.2023 21:34+3Потом можно заполировать этим — по большому счёту «the managerial revolution:
2060 лет спустя».Нельзя пройти мимо обсуждения иерархии менеджеров и не вспомнить об этом.
im_last
15.01.2023 04:24Возможно, не у всех необходимый уровень осознанности, что бы понять основную суть.
wzei
13.01.2023 17:38+2Мне не понятно, почему автор не рассмотрел проблему начиная с 50-х годов, когда начали появляться первые языки высокого уровня? Не упомянул попытки создать эффективные метакомпиляторы в 60-70 (спойлер: они провалились из-за лавиообразного роста сложности обсчета возможных ветвлений в программе)? Почему автор не раскрыл сути отношений между всеми участниками разработки, которые и приводят к тому выгоднее иметь армию средненьких разрабов, чем десяток ученых с тем же метакомпилятором (который остался между мечтами и яблонях на Марсе и коммунизмом к 80-му году из-за проблем, описанных выше)? Почему "правильные цитаты" - это просто цитаты, сдобренные ярлыками, рваным повествованием и историей на подобие притчи. И уже заданные вопросы по сути своей повторяют то, что авторы цитат вкладывали в свои работы без необходимости ярко выставлять их напоказ, рассчитывая на эпотаж публики. Вот это получилось на все 100%, спорить не буду.
Поэтому я не соглашусь с теми немногими из комментаторов, кто пытается подержать автора, мол, как же хорошо, что он привел "правильные цитаты". Только проблема-то в том, что цитаты не канают, когда прямо тут же автор их неявно и опровергает выбранным методом рассуждения.
Pastoral
13.01.2023 17:42+2В части касающейся программистов положения статьи доказаны комментариями блистательно.
О двух причинах, страстям по взаимозаменяемости и привязке к выданному рабочему месту, навязчиво думалось при чтении статьи по соседству, о двух культурах в программировании. Вот и ещё подтверждение - то были два лица одной культуры, капитал-корпоративной.
Не вчера оно началось. Привязка любыми подлостями к серверу - прокатило, тревожно смотреть что на репозитарии Линукс что на хранилища типа crates.io, pub.dev, да и github.com - отключается и цензурируется в пол пинка. Прямые запреты - прокатило, на залоченные загрузчики, эксклюзивные магазины, W^X политику даже бухтеть перестают. Прямое оболванивание - прокатило, один Тик Ток чего стоит.
И дальше (и вообще) всё идёт (и будет идти) по плану. Ибо новые бараны рождаются каждый год, а пастухи меряют историю тысячелетиями. Как позитив - Borland же кому-то в тридорога продаёт и C++ таки развивается. Как негатив - учёные тлейлаксу тоже всегда досыпали позитива до теоретической возможности выживания.
ednersky Автор
13.01.2023 17:45Как позитив - Borland же кому-то в тридорога продаёт и C++ таки развивается
Не знаю-не знаю. Вот Sun продался кому-то "в тридорога" и что получилось? Мир де-факто потерял операционную систему от Sun. Навсегда. Со всеми наработками и достижениями.
d0lfin
14.01.2023 09:18+1"В части касающейся программистов положения статьи доказаны комментариями блистательно."
Читаю комментарии ровно с той же мыслью! Все в шорах своих технологий, спорят про goto и микросервисы, а сути данного произведения не видят(
Как написал автор: «Фрагментарность мышления выражается в склонности программиста зацикливаться на частностях или мелочах, не глядя на картину в целом.»gatoazul
14.01.2023 15:02+1Какая там суть. Люди просто триггерятся на отдельные слова, даже не дочитывая до конца.
Хотите пример? Смотрите, что дальше будет.
"В СССР не все было плохо".
Cerberuser
14.01.2023 15:36Очевидная истина, зачем её здесь высказывать-то?
gatoazul
15.01.2023 13:10Это триггер, если вы не поняли. Для натурного эксперимента.
Cerberuser
15.01.2023 13:14Ну так а в чём смысл эксперимента-то? Выявить людей, не способных к логике?
safinaskar
13.01.2023 18:06А вообще спасибо за статью. Я, конечно, по-прежнему не согласен. Но, кажется, теперь понял, почему почти во все языки добавили ООП. В C добавили (получился C++), в Pascal и даже в Caml (получился Ocaml). Потому что ООП - это способ писать большим коллективом взаимозаменяемых программистов, то же, что микросервисы, но на другом уровне. Ну то есть я это и раньше понимал, а теперь окончательно осознал. Наличие ООП в языке - это своего рода печать "Данный язык можно использовать в бизнесе". Все побежали эту печать получать
xenon
14.01.2023 01:34И мейнстримные фреймворки - тоже для этого же. Можно и свой фреймворк иметь и самому развивать (хотя зачем? но это другой вопрос). Но фреймворк - это, условно пусть 50% всего проекта. И если приходит программист знающий популярный фреймворк - он уже на 50% знает ваш проект. А если у вас свой велосипед, то каждый новый программист должен еще и его учить.
AMDmi3
13.01.2023 18:17+1Посыл статьи понял как негодование покушением на собственную незаменимость. К дискуссии по сути она не располагает, потому что вы сходу ставите диагнозы.
vkni
13.01.2023 18:54+2Есть масса претензий к техническим деталям (динамика-статика, goto, которые у Дейкстры были longjmp, а не Cшные), но это совершенные мелочи. Основная идея подмечена хорошо. Спасибо.
event1
13.01.2023 19:08+8Автор накидал разных проблем и сделал из них вывод, о том, что надо объединяться и заканчивать с господством капитала.
Вывод правильный, но проблемы собраны произвольно и никак друг с другом не связаны. Сравнение внедрения микросервисов с отчуждением результатов труда рабочих не выдерживает никакой критики. Как будто результаты труда разработчиков монолитов не отчуждаются. Ссылаться в одной статье и на Ленина и на Богданова, тоже так себе идея.
по проблемам:
goto. Дийкстра был против широкого упротребления goto людьми, которые не понимают, что это за собой несёт. Короче, goto не для джунов. Взрослым можно.
исключения. Разработчики насмотрелись на плохо сделанную обработку исключений в больших проектах и решили, что проблема в самих исключениях (по аналогии с предыдущей ситуацией). История покажет, были ли они правы. Кстати, обработка ошибок в русте макросом "?", с точки зрения кода, мало отличается от джавовских checked исключений.
фрагментарное сознание. Скорее всего ничего не поменялось, просто мы получили возможность заглянуть в содержимое голов массы соучастников
история из Яндекс.Такси — обычный "кровавый энтерпрайз". Управлять большой массой людей без стандартизации невозможно. При коммунизме стандартов будет ещё больше. И среди них тоже будут чрезмерно универсальные
ednersky Автор
14.01.2023 11:50Ссылаться в одной статье и на Ленина и на Богданова, тоже так себе идея.
эм? а что тут не так? если бы я ссылался на Троцкого и Ленина, то да, это было бы так себе.
но Богданов ЕМНИП Ленину не противопоставлялсяevent1
14.01.2023 17:35Богданов — субъективный идеалист. Ильич вскрыл его сущность в известной работе "Материализм и эмпириокритицизм". Конкретно Тектологию не читал, но идея "добавить науку объединяющую все прочие" звучит крайне сомнительной.
ednersky Автор
14.01.2023 18:51+1Эм… ну и Маркс с Гегелем как бы тоже спорили: "Бытие определяет сознание" (Маркс) — как по мне — радикально ошибочная теория. То есть она работает да, но только в областях приграничных к небытию. И Маркс о них же и пишет: бытие формирует человека с малолетства попавшего в определённые условия, итп.
Здесь он прав.Однако если отойти от границы с небытием, то очень часто берёт верх Гегелевское "Бытие определяется сознанием". В эту кучу сыпем все примеры от самопожертвований, вроде Матросова, Гастелло, до многих политических решений/выборов в том числе очевидно вредных с точки зрения того самого бытия.
если всё сводить к курице или яйцу — "что первично, бытие или сознание?", то тут Маркс и Ленин очевидно будут правы: природа существовала до появления сознания и независимо от него (Ленин по той ссылке, что вы привели).
если же двигаться к диалектике, которая учит нас рассматривать явление в динамике, то и постулаты Гегеля будут вполне работать на материалистическом поле.
впрочем я куда-то в сторону сбился.
Ленин спорил по философским вопросам со многими, вот, в частности, с Гегелем. Что с того? Гегель от этого стал менее велик? Его не нужно больше изучать?
Если же вернуться к Богданову, то по ссылке Ильич не "вскрыл его сущность", а всего лишь имел с ним спор по условно одному из десятков прорабатываемых Богдановым вопросов. Спор о материалистических/идеалистических основах мироздания ну никак не мешал им обоим понимать одинаково смысл разделения труда, необходимость преодоления эксплуатации человека человеком итп.
как-то так.
event1
14.01.2023 20:47Ленин спорил по философским вопросам со многими, вот, в частности, с Гегелем. Что с того? Гегель от этого стал менее велик? Его не нужно больше изучать?
Просто если вы идеалист, то странно апеллировать к материалистам Марксу и Ленину и их строго материалистическим теориям. Если же вы, напротив, материалист, марксист и ленинист, то ссылка на "эмпериомонадиста" Богданова выглядит нелепо.
ednersky Автор
14.01.2023 21:04Просто если вы идеалист, то странно апеллировать к материалистам Марксу и Ленину и их строго материалистическим теориям. Если же вы, напротив, материалист, марксист и ленинист, то ссылка на "эмпериомонадиста" Богданова выглядит нелепо.
проблема оператора goto — в том, что его противники всё абсолютизируют и золотой середины не признают.
"Если goto запихать в каждую строку кода, то получится фигня!" — говорят они, и делают вывод: "goto не нужен!"
Ровно тот же подход предлагаете и вы сейчас. Вы предлагаете ни в коем случае не рассматривать достижения различных философских систем.
А между тем это радикально невзаимозаменяемые множества.
Вот взять Маркса, он сформулировал термин "отчуждение" и предложил варианты (или нарисовал родмап) как это можно преодолеть. Маркс — материалист? Да, до мозга костей.
Но попробуйте ответить на вопрос: ЗАЧЕМ преодолевать отчуждение?В чём цель?
чтобы человек перестал быть заложником подавляющих внешних факторов (если не ходить по ссылкам дальше википедии)
а что такого в том что он им является?
если вы порефлексируете над этим то неизбежно придёте к тому, что всё упрётся в понятия "хорошо" и "плохо", ну и заодно в понятие справедливости.
плохо — когда человек — винтик, хорошо — когда он творец
плохо — когда человек — раб, хорошо — когда он свободен
несправедливо — когда человек по праву рождения не равен другим, справедливо — когда наоборотну и так далее
и вот если мы рассмотрим философские понятия "хорошо" и "плохо", "добро" и "зло", "справедливость" итп, то с удивлением обнаружим, что на протяжении тысяч лет разработкой этих понятий, классификацией, формулировкой занималась… сугубо идеалистические организации, движения — религии.
а материалистическая наука, напротив, дистанцируется от этих понятий. не берёт на себя груз ответственности выдачи и разработки подобных формулировок.
Итого: материализм (по кр мере Марксов) в своём базисе имеет идеалистические целеполагания.
Вывод: рассматривать изолированно материализм и идеализм можно, противопоставлять их нельзя.
Диалектика!event1
14.01.2023 21:42проблема оператора goto — в том, что его противники всё абсолютизируют
Задача инженера состоит в том, чтобы решить проблему лучшим образом наличными средствами. Хорошо то, что помогает решить проблему. По-этому, слепая вера вредит инженеру. К мировоззрению это не имеет никакого отношения
Ровно тот же подход предлагаете и вы сейчас. Вы предлагаете ни в коем случае не рассматривать достижения различных философских систем.
Отнюдь. Но как можно быть одновременно материалистом (= утверждать, что существует материальный мир не зависимый от сознания) и субъективным идеалистом (= утверждать, что мир существует только в сознании субъекта) у меня в голове не укладывается. По-моему, это два взаимно-противоположных взгляда на мир и в систематизированной картине мира ужиться одновременно не могут.
Но попробуйте ответить на вопрос: ЗАЧЕМ преодолевать отчуждение?
Да запросто. Во-первых, потому что это не справедливо (с социалистической точки зрения). Во-вторых, люди работают на себя намного лучше чем на дядю. И если им отдавать плоды их труда, то они будут работать лучше и тогда им придётся работать меньше. Через это у них останется больше свободного времени. Это прогресс. Предвосхищая ваш вопрос, "зачем прогресс?", не знаю, но мир устроен так, что прогрессивное вытесняет регрессивное. По-этому, лучше быть прогрессивным, чем регрессивным.
на протяжении тысяч лет разработкой этих понятий, классификацией, формулировкой занималась… сугубо идеалистические организации, движения — религии.
Любой интеллектуальной работой на протяжении тысяч лет занимались представители религии. Коперник был священником, например. Пастер был католическим фанатиком. Имели ли религии какое-то прогрессивное значение? Да, в древности имели. Должны ли мы тянуть религиозные догмы в 21-ый век? Очевидно, нет. Почему? Потому что объяснение чего бы то ни было на основе мифов четырёхтысячелетней давности сегодня выглядит просто смешно.
несправедливо — когда человек по праву рождения не равен другим, справедливо — когда наоборот
мы с вами выросли в социалистическом интеллектуальном окружении и по-этому этот тезис для нас с вами очевиден. Однако, 1000 лет назад для большинства людей правильным было прямо противоположное утверждение.
а материалистическая наука, напротив, дистанцируется от этих понятий. не берёт на себя груз ответственности выдачи и разработки подобных формулировок.
Потому что это бессмысленное словоблудие. Не бывает абстрактного "хорошо", "плохо" или "справедливо". Есть интересы людей и классов. Когда их интересы соблюдаются — это хорошо и справедливо. Когда нарушаются — плохо.
Итого: материализм в своём базисе имеет идеалистические целеполагания.
Вы их сами только что выдумали, эти "идеалистические целеполагания". У материализма (как впрочем и у идеализма) цель описать мир. Точнее дать базис для такого описания.
ednersky Автор
14.01.2023 21:50ну блин
даже вы же на вопросы отвечаете "потому что это не справедливо", "лучше чем" итп
и при этом же противоречите себе что определять "хорошо" и "справедливо" с точки зрения материализма — "бессмысленное словоблудие".
соответственно либо цели к которым движутся материалисты — словоблудие.
в этом случае они совершенно бессмысленнылибо смычка материального и идеального имеет право на существование и вот я нашёл её у Маркса, не вижу ничего плохого (и Ленин не видел) в том, что она была у Богданова, ну и так далее
event1
14.01.2023 22:03даже вы же на вопросы отвечаете "потому что это не справедливо", "лучше чем" итп
Потому что мы с вами существуем в одном и том же инфополе и каждый раз добавлять "с точки зрения рабочего класса" или "для рабочих" или "для прогресса", я нахожу назойливым и скучным. Оно и так понятно.
и при этом же противоречите себе что определять "хорошо" и "справедливо" с точки зрения материализма — "бессмысленное словоблудие".
Определять вообще "хорошо" и "справедливо" бессмысленно. Потому что это относительные понятия. То есть "хорошо" и "справедливо" бывает только для кого-то.
соответственно либо цели к которым движутся материалисты — словоблудие. в этом случае они совершенно бессмысленны
Материалисты никуда не движутся, так как они не являются организацией и не представляют из себя сообщество.
смычка материального и идеального имеет право на существование и вот я нашёл её у Маркса
Вы её додумали у Маркса. "Нашёл", это если бы вы цитату привели.
ednersky Автор
14.01.2023 22:21Потому что мы с вами существуем в одном и том же инфополе и каждый раз добавлять "с точки зрения рабочего класса" или "для рабочих" или "для прогресса", я нахожу назойливым и скучным. Оно и так понятно.
какая разница с точки зрения рабочего класса или прогресса?
мы же о понятиях "хорошо" и "плохо"
если материализм отказывается их формулировать, но формулировки использует, то получается материализм базируется на идеализме. По крайней мере в целеполаганиях, по крайней мере марксистский материализм в той его части, где предполагает решения проблем отчуждения.
Материалисты никуда не движутся, так как они не являются организацией и не представляют из себя сообщество.
я всё время подчёркиваю — что не все материалисты, а та часть, которая про марксизм. и в этом сообщении и в предыдущих.
ЗАЧЕМ преодолевать отчуждение?
ЗАЧЕМ увеличивать (до 100% в идеале) количество творческих личностей?event1
14.01.2023 22:38какая разница с точки зрения рабочего класса или прогресса?
мы же о понятиях "хорошо" и "плохо"
Потому что это относительные понятия. Сами по себе они не имеют смысла. Если не читали, гляньте "Диалоги" Платона. Там Сократ страниц на 500 пытается выяснить, что такое "добродетель" вообще.
я всё время подчёркиваю — что не все материалисты, а та часть, которая про марксизм. и в этом сообщении и в предыдущих.
Марксисты тоже разные бывают. Каждая организация определяет сама для себя куда ей двигаться.
ЗАЧЕМ преодолевать отчуждение?
ЗАЧЕМ увеличивать (до 100% в идеале) количество творческих личностей?
Потому что это прогресс. Предвосхищая ваш вопрос, "зачем прогресс?", не знаю, но мир устроен так, что прогрессивное вытесняет регрессивное. По-этому, лучше быть прогрессивным, чем регрессивным.
ednersky Автор
14.01.2023 22:45Потому что это относительные понятия. Сами по себе они не имеют смысла. Если не читали, гляньте "Диалоги" Платона
а Платон — кто? разве не идеалист? как вы можете апеллировать к идеалисту в материалистических вопросах?
(видите, я тоже могу подобные вопросы задавать :P)
Марксисты тоже разные бывают
и идеализм Богданова не мешал ему быть марксистом, заниматься пролеткультом и прочим
материализм Ленина не мешал ему поддерживать идеалиста Циолковского.
Вы же помните историю, почему Циолковский занялся ракетным движением?
пришёл он как-то в гости к русскому космисту Фёдорову, а тот ему и говорит: в ближайшее будущее мы воскресим всех умерших людей на планете и представляешь что будет? тотальное перенаселение!
Циолковский так впечатлился, что решил заняться способами освоения космического пространства.
event1
14.01.2023 22:55а Платон — кто? разве не идеалист? как вы можете апеллировать к идеалисту в материалистических вопросах?
Это не апелляция, а отсылка к примеру бессмысленного словоблудия. Порождённого идеализмом. Но Платона можно простить, он древний.
материализм Ленина не мешал ему поддерживать идеалиста Циолковского.
Вы путаете философскую базу и политическую практику. Если бы у Ленина был принтер для печати идеальных людей, то можете не сомневаться, все его соратники, сотрудники и подчинённые были бы идеальными. Но, в реальной жизни приходится работать с тем кто есть. Политика, как говорится, — это искусство возможного.
ednersky Автор
14.01.2023 22:58Вы путаете философскую базу и политическую практику. Если бы у Ленина был принтер для печати идеальных людей, то можете не сомневаться, все его соратники, сотрудники и подчинённые были бы идеальными. Но, в реальной жизни приходится работать с тем кто есть. Политика, как говорится, — это искусство возможного.
Сталинское: "других писателей у меня для вас НЭТ".
так что, снимаем тезис о некорректной отсылке к Богданову и Тектологии? Ни идеализм Богданова не влияет на "политическую практику" ни отсутствие/присутствие материалистичных альтернатив.
ednersky Автор
14.01.2023 22:47Предвосхищая ваш вопрос, "зачем прогресс?", не знаю
ну вот, чем отвечать на вопросы — фиксируем отказ от их рассмотрения.
я вас не упрекаю, просто констатирую факт
Cerberuser
14.01.2023 22:47ЗАЧЕМ преодолевать отчуждение?
Смотря кому.
ЗАЧЕМ увеличивать (до 100% в идеале) количество творческих личностей?
Чтобы те, кто не хотят ими быть, вымерли и не мозоли глаза.
iig
14.01.2023 23:32-1И если им отдавать плоды их труда, то они будут работать лучше и тогда им придётся работать меньше.
Допустим, рабочий на сверлильном станке сверлит дырки в деталях. Если результат его работы не очуждать - зачем ему сколько дырок? А другой рабочий вырубает детали с помощью пресса. Если результат его работы не отчуждать - первому рабочему негде будет сверлить дырки.
ednersky Автор
14.01.2023 23:35у Джека Лондона (список литературы выше) есть ответ на этот вопрос, почитайте
randomsimplenumber
15.01.2023 10:01+1Я читал и более современную фантастику. Там расширяться капитализму было уже некуда. Но выход был найден: кредиты. Там люди покупали всё в кредит, с обязательством оплаты ещё неродившимися детьми и внуками. Тоже неплохо. Разрядности компьютера хватит для хранения долговых обязательств.
Капитализм - это способ обеспечения экспоненциального роста экономики с помощью капитала, всего лишь. Экспорт в слаборазвитые страны - это не обязательно капитализм, так и в древнем Риме делали.ednersky Автор
15.01.2023 10:04Я читал и более современную фантастику. Там расширяться капитализму было уже некуда. Но выход был найден: кредиты. Там люди покупали всё в кредит, с обязательством оплаты ещё неродившимися детьми и внуками
ну да, описания этой самой железной пяты у многих писателей присутствует.
а вот рассмотрения «как её избежать» — почти ни у кого. поэтому классики всё ещё и остаются классиками.
ednersky Автор
15.01.2023 10:11Я читал и более современную фантастику. Там расширяться капитализму было уже некуда. Но выход был найден: кредиты. Там люди покупали всё в кредит, с обязательством оплаты ещё неродившимися детьми и внуками
кстати, вы (ну или те фантасты) тут почти сформулировали религиозное понятие «первородный грех».
а заодно другое, что царь/боярин/ну или вообще власть — наместники бога на земле — поскольку безгрешны
PS: Если почитать современных фантастов, то крайне часто натыкаешься на описание вариаций родо-кланового общества.
почему они не решаются поискать в своих фантазиях более справедливое общественное устройство, как вы думаете? почему классики решались, а они нет?
причём классики решались не только на рассмотрение социализма, но и иных видов общества.
Взять например: «Град обречённый» Стругацких.
Как по мне, так лучше жить в этом граде, нежели в родо-клановом обществе, которое так часто рисуют современные фантасты.
менее тошно что ли, ну и более справедливо
iig
15.01.2023 15:55почти сформулировали религиозное понятие «первородный грех».
Ничего удивительного ;) Все сюжеты уже встечались ранее - либо в Библии, либо у Шекспира, либо в ЮжПарке. Так же как все алгоритмы придуманы в 70-80х годах.
Если почитать современных фантастов, то крайне часто натыкаешься на описание вариаций родо-кланового общества
Если дать фантасту машину времени, он загадит своими попаданцами всё до самого мезозоя (ц)
Эскапизм неплохо продается, вот и весь секрет удивительного долголетия ёжиков.
иных видов общества.
Для иных видов общества, подозреваю, нужны более другие виды человеков.
ednersky Автор
15.01.2023 17:27> неплохо продается, вот и весь секрет
я пытался вас сподвигнуть на рефлексию: почему он неплохо продаётся?
мой ответ таков (я выше озвучивал): что справедливого общества даже в фантастических чаяниях люди не видят.
и это повод для серьёзного уныния, на самом деле
> Для иных видов общества, подозреваю, нужны более другие виды человеков.
человека отличает от животного то, что он может становиться над инстинктами и, соответственно, менять правила игры и меняться сам.
ваш же человек — от животного отличий не имеет, а потому в чём смысл его существования?
iig
15.01.2023 21:51справедливого общества даже в фантастических чаяниях люди не видят.
Это называется систематическая ошибка невыжившего. Люди, наблюдавшие как оно выглядит, это справедливое общество - что они должны увидеть?
человека отличает от животного то, что он может становиться над инстинктами и, соответственно, менять правила игры и меняться сам
Да, говорят, что именно затем Моисей водил евреев 40 лет по пустыне. Не уверен, что у него всё получилось.
ednersky Автор
15.01.2023 10:19> Я читал и более современную фантастику. Там расширяться капитализму было уже некуда.
а ещё помимо фантастики, на тему «расширяться более некуда» у нас есть ещё и история. И даже название тому, что растёт из «расширяться более некуда» — дано звучное — Тёмные века.
JC_Fruit
13.01.2023 19:28+3Простите, нет сил перечитывать все сотни комментариев, что бы понять, высказывал кто-то похожие мысли или нет
Но не было ли у автора мысли, что история про 50 строк кода - это не история про микросервисы и стандарты, а история про политику и деньги?
В конце концов, сэкономить бизнесу миллиард рублей в месяц ценой 50 строк кода - это достижение одного разработчика. Которое еще и не будет оценено по достоинству (хотя бы из за огромного несоответствия масштаба усилий и выхлопа), а сэкономить миллиард в месяц ценой создания огромной системы с нуля и привлечения нескольких новых команд - заслуга CTO, который потом будет соответствующе награжден и сможет этим везде хвастаться.xenon
14.01.2023 01:41Мне кажется, эта история - пример того, что у каждого правила есть недостатки (и тем не менее, достоинства их перекрывают). Допустим кто-то может предложить маааленький патчик, который нам много что даст, и "что тут думать, прыгать надо, давайте уже по быстрому в продакшн!". А злые бюрократы не дают. А патчик в самом деле маленький и безопасный. Но если мы открываем возможность для всего, что "вроде безопасно", то сегодня у нас будет этот патчик, завтра другой, а через пять дней будет тот, который казался безопасным, но что-то непредусмотрели и грохнули весь бизнес.
Надо просто понимать и принимать, что многие правила - не идеальны. В них есть минусы, эти минусы стоят деньги. Но даже в этом неидеальном виде они полезны и их приняли осознавая эти минусы.
ednersky Автор
14.01.2023 11:47+1Но не было ли у автора мысли, что история про 50 строк кода — это не история про микросервисы и стандарты, а история про политику и деньги?
была, и эта мысль привела к данной статье: о политике и капитале :)
amazed
13.01.2023 20:26Так уж люди устроены. Например, они тысячелетиями верили, например, что если молиться каждый день и ходить в церковь, это поможет решить в том числе и материальные проблемы.
Теперь целая отрасль верит что определенные вещи эффективны потому что все их применяют а не потому что есть доказательства их эффективности. Микросервисы (когда они становятся действительно "микро") возможно одна из таких легенд.
Но в целом это работает. А главное - это способ победы над безработицей. Когда сложную задачу решает 3 гения, остальным нечего делать. Это дешево не не стабильно. Когда ее же решают опять эти три гения, но которые не имеют право все закодить сами, а вместо этого у них в подчинении 100 не-гениев, это дороже, но стабильнее. И у всех есть работа.
Можно взять, например фреймворк, в котором достаточно добавить поле в один класс и оно сразу будет доступно в браузере без пяти маперов и промежуточных перекладываний. Можно истребить все разнообразные инструменты и оставить один для каждой цели.
Но к счастью или к несчастью, по этому пути мы не идем. Вместо этого в каждом проекте нужно 100 обезьян, которые будут кропотливо изучать документацию по каждому инструменту, который решили использовать, а потом писать кучу кода по перекладыванию данных. Зато этот процесс гибкий, масштабируемый и у всех есть работа...
xenon
14.01.2023 01:47Воевать с безработицей и создавать "скрытую безработицу" (рабочие места для людей, которые делают пустую работу) - это задача государства. Мало какой капиталист наймет за свои деньги 10 человек там, где справятся 3.
А фреймворки жирнеют по обычной причине - маленький фреймворк идеально подходит для маленького проектика. Но... чего-то в них нет и для другого проекта не подходят. Тогда добавляют одну фичу. Потом другую. Потом фич так много, они конфликтуют, и надо их как-то подключать-отключать. И появляется включалка-отключалка.... Фреймворк становится жирным, в нем дофига всяких ненужных (в простой задаче) плюшечек... И появляется новый лайтовый фреймворк, который идет тем же путем.
Мне в этом плане понравилась философия Svelte: Пусть лучше этот проект любит небольшое количество людей, чем ненавидят все. (Хотя с выходом их SvelteKit, мне кажется, они шагнули слишком уж вширь и простые вещи стали сложными, отступили от принципа).
amazed
15.01.2023 11:09Второй обзац вашего сообщения объясняет противоречие, высказанное в первом - почему бизнес борется с безработицей, хотя это не в его интересах. Потому что так получается по логике развития технологий.
borv
13.01.2023 20:41+1Аналитики: этонужнобизнесу!
Менеджиент: Боги хотят больше кода! Больше кода для богов!
Инженеры: Нифиганепонял, вот вам копипаста из соседнего проекта.
Реальность: Вы родили очередную метрику формата "килограмм ежа на квадратный метод ужа" на которую всем будет плевать через три недели включая авторов. Кстати она у вас сломана....через 6 месяцев
Инженеры: мы не можем сделать эту фичу она поломает метрики. В частности еж-кг/уж-м2.
Бизнес: Чииво? Аналитики!
Аналитики: Это не мой проект, надо месяц на погружение.
Менеджеры: Ломать нельзя! Богам надо больше кода и быстрее!
Инженеры: Три недели.
Бизнес: х..ли все так медленно? Чем вы там вообще занимаетесь?...через 10 лет
Аналитики: этонужнобизнесу!
Менеджиент: Боги хотят больше кода! Больше кода для богов!
Инженеры: (1) найдите технического хозяина, (2) напишите спецификацию по стандарту, (3) договоритесь о SLO, (4) положите TCO+20% в бюджет, (5) мы напишем микросервис/пайплайн и т.д.
Бизнес: блин это долго, сложно, дорого и нудно. Оно нам вообще надо?
Инженеры: не благодарите!Яндекс контора немаленькая, в описанной ситуации "надо узнать почему..." вероятно надо было узнать не так уж сильно. Рискну предположить что прямо даже наоборот.
SteamEngine
13.01.2023 20:49груг очень любит системы типов упрощают программирование. для груга системы типов самая польза когда груг нажимает точку на клавиатуре и магией открывается список что может сделать груг. это 90% пользы от системы типов для груга
ri_gilfanov
13.01.2023 21:15addition. груг плачет, когда на экран выпригивает ZeroDivisionError. груг не тестирует пограничные случаи. груг не читает документацию. груг не документирует исключения.
gatoazul
14.01.2023 15:06И именно это не дает развиваться языкам в сторону большей абстрактности и выразительности. Зачем, если можно сочинить 100500 методов для объекта и заставить их потом выбирать по точке?
ri_gilfanov
13.01.2023 20:56Думаю основными противниками исключений являются разработчики делающие ставку на развитую и явную систему типов. Например, если Вы пишите на Python и используете MyPy для статической проверки типов -- возникает естественный соблазн заменить исключения на возвращаемые ошибки. Тогда Вам не придётся помнить какие исключения могут быть подняты в тех или иных вызовах. Тогда IDE явно будет Вам подсказывать, что функция может вернуть, скажем, целое число или объект типа AttributeNotFound. Хотя, быть может, тут система типов, пытаясь вытеснить из языка исключения, выступает в роли антипаттерна "золотой молоток" (иллюзия универсальности инструмента). Полностью отказаться от исключений и явно обрабатывать ошибки на всём стеке вызовов -- верный способ воссоздать проблему, которую уже решили в 1970-х годах... придумав исключения.
WraithOW
13.01.2023 22:46+3Однако постепенно такие возможности закрываются и далее будут закрываться ещё агрессивнее. По мере роста отчуждения труд разработчиков будет всё сильнее дешеветь, пока из нынешних хипстеров не получатся настоящие пролетарии.
Вот это, если задуматься, очень интересный пассаж в контексте примера с Яндекс.Такси. Потому что так-то источник прибавочной стоимости - это таксист. Он крутит баранку, следит за уровнем омывайки и развлекает пассажиров рассказами о том, чем сам любит заниматься для души. Эту стоимость у него изымает Яндекс и распределяет внутри себя. А автор, будучи сотрудником Яндекса, является по сути, пособником в этом процессе угнетения рабочего класса.
Эксплуататор жалуется на эксплуатацию. Прелестно-с.
ednersky Автор
14.01.2023 11:42+1Эксплуататор жалуется на эксплуатацию. Прелестно-с.
рабов на плантациях охраняли… рабы.
разве они были эксплуататорами?WraithOW
14.01.2023 15:14+2Это вы товарищам из ЧК затирать будете.
ednersky Автор
14.01.2023 16:48паяц
WraithOW
14.01.2023 16:51Ответов-то по существу ждать, или язык проглотил?
https://habr.com/ru/post/709328/comments/#comment_25109076
https://habr.com/ru/post/709328/comments/#comment_25109108
WraithOW
14.01.2023 15:49+6Разверну мысль, а то до вас же не дойдёт. Вы сознательно выбрали работать в большой компании, которая сыграла наибольшую роль в падении доходов таксистов за последние десять лет. Вы вполне могли отнести своё резюме в небольшой таксопарк, или стать частью таксистской артели, и получать там справедливую зарплату на том же уровне, что и сами таксисты. Вместо этого вы сознательно, ради личной выгоды, отправили своё резюме монополисту.
Вы не раб - у тех не было выбора, что сказали, то и делаешь. Вы человек низких моральных качеств, который не в состоянии нести ответственность за свои поступки в соответствии со своими же убеждениями. Иными словами - "чуждый рабочему классу элемент", которых в последнюю революцию на ура в прорубях топили.
Olpo
13.01.2023 22:47Мы отрицали goto, как могли...
получили for->if->break/continue и switch->case->break
ednersky Автор
13.01.2023 23:56-4
Информация к размышлению... Штирлиц шёл по корридору...
Избыть из себя лакея крайне сложно. Начать думать - ещё сложнее.
anone18236
14.01.2023 08:44+5Избыть из себя лакея крайне сложно. Начать думать - ещё сложнее.
Не волнуйтесь, главное- не здавайтесь, и у вас все получится.
PsihXMak
14.01.2023 03:19А в чём проблема с исключениями? Много слышал, пытался разобраться, но какой то внятной информации, почему исключения это хорошо/плохо не нашёл. При этом почти в любом учебном материале всегда присутствуют способы создания и обработки исключений.
aegoroff
14.01.2023 08:46+1А в чём проблема с исключениями?
управление передается непонятно куда (фактически это тот же goto, только замаскированный) это раз, это весьма медленно (примерно на 3 порядка медленнее чем классическая обработка ошибок) это два, очень часто это неправильно используется (например вместо условной логики для изменения хода программы) это три.
PsihXMak
14.01.2023 13:36Спасибо. Возможно подскажете ещё с одним вопросом. Я слышал про концепцию об отказе от NULL. Особенно, что нельзя возвращать null из метода. Однако получается, что если в методе возникает некая ошибка, то мы не должны ни null возвращать, ни exception вызывать. И у меня диссонанс по этому поводу.
aegoroff
14.01.2023 15:50Есть разные подходы:
Классика Си - коды ошибок, обычно возвращается как результат выполнения функции, а настоящий результат который должна вернуть функция, устанавливается по указателю, на внешние данные, которые эта функция должна инициализировать или установить. Например в Apache Portable Runtime, почти все функции возвращают apr_status_t (это альяс для int), а результаты устанавливают по указателю https://apr.apache.org/docs/apr/1.7/group__apr__dir.html
Можно как в Go - из функции или метода возвращается кортеж, где первый параметр возвращаемое значение, а второй ошибка - если она не null что делаем для это или игнорируем - об этом собственно и идет речь в тексте
Можно как в Rust - возвращать enum Result первый аргумент которого полезная нагрузка, а второй тип ошибки. Обрабатывается это по разному - можно прокинуть наверх через оператор ? (но тогда вызывающий метод тоже должен возвращать Result), обработать внутри через match или if/let, обработать внутри через unwrap() или expect() - в случае ошибки приложение сразу грохнется, обработать чере unwrap_* - c установкой некоего значения по умолчанию или кода который вернет нужное значение.
Что-то другое, но на ум пока ничего не приходит
gandjustas
14.01.2023 17:09+1Первая и единственная реальная проблема исключений - скорость. Исключения очень медленные. Настолько, что выгоднее написать проверку условий до вызова или вернуть код ошибки. Слава богу сейчас реализация исключений такова, что дополнительные расходы на исключения минимальны когда они НЕ выбрасываются. Но когда выбрасываются это очень медленно.
Вторая проблема исключений - в подавляющем большинстве случаев их не надо перехватывать, но программисты все равно это делают.
И тут возникает здравая идея: давайте поделим все исключения на те, которые не надо перехватывать (например Usage Exceptions) и те, которые можно перехватывать (IOException, SocketException). Первые пусть приводят к падению программы, а вторые заменим возвратом кода ошибки. Примерно так и подумали в Rust и Go.
Но эта идея хороша только на первый взгляд, так как длинный код из последовательных IO операций с возвратом ошибок становится нечитаемой кашей.
В Rust вроде одумались и собираются ввести автоматическую обработку исключений. Плюс там возврат кода ошибок делается через or-типы, у которых есть методы превращающие перехватываемое исключение в неперехватываемое.
В Go нет таких типов, там функция возвращает два значения, а не одно значение специального типа. И хорошего решения нет.
Монданый синтаксис мог бы помочь в этой ситуации, но его нет ни в Rust, ни Go.
Ну и третья проблема, скорее идеологическая - выбрасывание и перехват исключений это аналог Goto, из-за чего могут не выполниться важные части кода. Но фактически это не проблема, так как нормальные языки научились использовать try\finally и автоматически вызываемый код при выходе из scope.
ednersky Автор
14.01.2023 18:59Первая и единственная реальная проблема исключений — скорость
нет такой проблемы.
исключения совершенно точно не медленнее ручной проверки.
ибо когда вы пишете
result, error = foo() if error { return nil, error }то вы делаете ровно то же, что делал бы компилятор под капотом, если бы распространял исключения вверх по стеку.
BugM
14.01.2023 19:06ednersky Автор
14.01.2023 19:10Нет
хорошо, перефразирую немножко: вместо "вы делаете ровно тоже что делал бы компилятор", прочитайте "вы делаете то, что может делать компилятор".
я не сомневаюсь что в том или ином движке исключения могут быть реализованы так, сяк или об косяк, и даже не сомневаюсь в том что будут ссылки на это.
однако вот приведённый код (каждый foo возвращает пару "результат-ошибка" и ошибка распространяется return'ами вверх по стеку) является полным эквивалентом исключения и потому может быть реализован компилятором. А значит как минимум НЕ БЫТЬ медленнее ручных манипуляций
ну или перефразируя ещё одним способом: если утверждается, что вот это, написанное человеком — работает быстрее того, что есть в компиляторах, почему не взять это и не вложить в компилятор? Причин, мешающих так сделать, нет, а следовательно высказывание что "проблема исключений — скорость" — ложно
BugM
14.01.2023 19:15+1Я вам показал бенчмарк из реального мейнстримного языка программирования. Давайте добавлю бенчмарк исключений в плюсах. Там ровно та же особенность https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/
Вы сделали не то что делается типовыми реализациями исключениеями. И не то что ожидает пользователь. Ваше поведение не реализует типовой контракт декларируемый исключениями со массовых языках. И его нельзя с ними сравнивать.
ednersky Автор
14.01.2023 19:18Я вам показал бенчмарк из реального мейнстримного языка программирования. Давайте добавлю бенчмарк исключений в плюсах
да блин мне всё равно на тот бенчмарк, я ведь о другом говорю. бенчмарк может по какой-то причине быть плохим. я вам говорю что можно сделать компилятор, бенчмарк которого будет минимум не хуже того кода, который лепят Go/Rust программисты в каждой первой функции
BugM
14.01.2023 19:22да блин мне всё равно на тот бенчмарк, я ведь о другом говорю. бенчмарк может по какой-то причине быть плохим
Вы код бенчмарка смотрели? Покажите что именно там плохо сделано. Или напишите хороший.
можно сделать компилятор, бенчмарк которого будет минимум не хуже того кода, который лепят Go/Rust программисты в каждой первой функции
Покажите пример. Исключение это определенная и довольно тяжелая сущность. Ее сделать стоит дорого. Интересно как ее создание кто-то смог сделать легким.
ednersky Автор
14.01.2023 20:45Вы код бенчмарка смотрели?
нет же.
Покажите пример.
вот же он показан
res, err = foo() if err { return nil, err }берём например ПРЕПРОЦЕССОР, и запихиваем мусор про проверки if err в него.
получаем что на уровне языка пользователь больше не манипулирует err'ами (там где ему не нужно), и пишет просто
res = foo()там где он напишет
try { } catch (err) { }препроцессор оформит вызов кода из catch блока вместо простого return.
СОВЕРШЕННО ТОЧНО этот подход не будет медленнее ручных вездесущих вставок
if err { return nil, err }amishaa
14.01.2023 21:30А как препроцессор узнает, какие функции нужно оборачивать в этот блок, а какие нет?
BugM
14.01.2023 23:01+1А как вы думаете почему минимум в двух массовых языках так не сделали? То что там языковые конструкции и их реализации придумывают глупые люди можно сразу откинуть.
Слово контракт вам о чем-то говорит? В применении к CS.
ednersky Автор
14.01.2023 23:18А как вы думаете почему минимум в двух массовых языках так не сделали?
в статье моё мнение об этом высказано
Cerberuser
15.01.2023 07:39Мнение заключается в том, что создатели языка - эксплуататоры, которым невыгодно делать такой язык, на котором было бы удобно разрабатывать приносящий им прибыль код, а выгодно - такой, на котором будет удобно эксплуатировать разработчиков?
amishaa
14.01.2023 19:55Не знаю про go, но про Раст это не так.
Проверять на err значение все вызовы дорого (по CPU). Идеология exception'ов: любая функция может выбросить любой эксепшен, но большинство вызовов err-значения возвращать не будет, поэтому exception'ы можно обрабатывать долго.
Другая альтернатива (выбранная Растом) звучит так: в compile time известно какие функции какие exception'ы может выбрасывать и проверять нужно только такие вызовы (а остальные проверять не нужно).
Знание во время компиляции нужно, например, для колбеков: возьмём тривиальную функцию, которая просто сразу зовёт полученный на вход колбек и больше ничего не делает. В Rust это будут разные функции, в зависимости от того, может ли колбэк бросать исключение или нет (и, в зависимости от этого, сама функция будет либо бросать, либо нет). В итоге если использовать первую функцию, то есть гарантии, что ошибки не будет (и проверять на наличие ошибки не нужно), а если вторую - то возможность ошибки появляется (и это видно по сигнатуре функции).
В какой-нибудь Java такого разделения сделать не получается, в итоге либо нужно все непрямые вызовы проверять на ошибки (что дорого, потому что ошибки случаются редко), либо дополнительно платить за обработку каждого исключения.
ednersky Автор
14.01.2023 21:33поэтому exception'ы можно обрабатывать долго.
поясните почему если код напишет разработчик то это дёшево, а если ТОТ ЖЕ КОД вставит туда препроцессор, то это дорого.
amishaa
14.01.2023 21:38Вставлять такую на каждый вызов каждой функции банально дорого.
Либо нужно вставлять только для тех вызовов, для которых нужно, либо, альтернативно, ни для каких не вставлять.
В первом случае разработчику (или компилятору, если он делает это сам) нужно уметь отличать вызовы, которые могут вызвать эксепшен от тех, которые не могут.
Во втором случае нужен отдельный механизм обработки эксепшенов, который не бесплатный.
ednersky Автор
14.01.2023 21:45Вставлять такую на каждый вызов каждой функции банально дорого.
а зачем вставлять в каждый вызов?
представьте что вы — компилятор.
Вы парсите функцию foo.На выходе у вас есть ответ на вопросы:
- может ли foo вернуть ошибку: да/нет
- список функций которые вызывает
- у каждой функции которые вызывает признак: возвращает ли ошибку
- у каждой функции которые вызывает кодовый блок обрабатывающий ошибку или его отсутствие
далее глядя на собранную информацию, вы очень легко НЕ вставляете в каждый вызов код там где он не нужен и вставляете там где он нужен
Ну компилятор Rust вон например времена жизни ссылок и владельцев контролирует. При этом владельцы могут через значительный стек присваиваний/вызовов функций передаваться. От чего с такой мелочью, как определение необходимости вставлять/не вставлять блок с ошибками было бы невозможно справиться?
amishaa
14.01.2023 21:52+1Так Раст и справляется, вроде бы. Просто это является (как и время жизни) частью сигнатуры функции. Если функция возвращает Result<T,E>, то это можно читать как "может вернуть T, а может бросить исключение E". Собственно, пробрасывание E наверх (если ты находишься в функции, которая может вернуть E, или, хотя бы, что-то к чему E приводится) делается одним оператором ("?").
Проблема примерно такая - если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
Kanut
14.01.2023 21:55Проблема примерно такая - если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
А это возможно? Ну то есть например в Java вы просто не сможете пометить функцию как не бросающую исключения если при этом она вызывает какие-то функции помеченные как бросающие. И при этом не обрабатывает эти исключения сама.
ednersky Автор
14.01.2023 21:57Ну то есть например в Java вы просто не сможете пометить функцию как
мы говорим о потенциальном препроцессоре же. а не о конкретном Java. конечно возможно
Kanut
14.01.2023 22:39Ну во первых человек вроде бы писал про конкретный раст.
А во вторых если это возможно, то у вашей идеи появятся огромные проблемы при использовании прекомпилированных библиотек и/или интерфейсов.
Потому что тогда ваш препроцессор не будет знать что там на самом деле происходит или не происходит внутри вызываемой функции.
ednersky Автор
14.01.2023 22:49Ну во первых человек вроде бы писал про конкретный раст
дык и я в статье про конкретный раст. перескок на Java в которой невозможно как раз и пытался отбить.
А во вторых если это возможно, то у вашей идеи появятся огромные проблемы при использовании прекомпилированных библиотек и/или интерфейсов
сигнатуры функций даже прекомпилированных известны?
Result<T,E> — считаем функцией могущей вернуть ошибку и врапаем её в функцию бросающую исключение и всего делов
Kanut
14.01.2023 22:53Result<T,E> — считаем функцией могущей вернуть ошибку и врапаем её в функцию бросающую исключение и всего делов
Хм, вы по моему не поняли о чём речь. А именно вот о таком поведении :
Проблема примерно такая - если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
ednersky Автор
14.01.2023 22:55Проблема примерно такая — если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
кем помечена? человеком? плевать на его пометки, их будет расставлять препроцессор
если помечена препроцессором, то это баг препроцессора — его надо исправлять
Kanut
14.01.2023 23:02+2А как препроцессор может что-то пометить если он не видит сам код? То есть например если используется интерфейс, а конкретная имплементация неизвестна?
ednersky Автор
14.01.2023 23:19А как препроцессор может что-то пометить если он не видит сам код?
а к чему же он ПРЕпроцессор?
Kanut
14.01.2023 23:22+3Например к тому коду, который вы сами написали.
Или ваш препроцессор в принципе не применим если например библиотеки могут динамически загружаться или даже заменяться уже во время выполнения программы?
ednersky Автор
14.01.2023 23:21То есть например если используется интерфейс, а конкретная имплементация неизвестна?
вот например есть typescript. работает так:
программист пишет на языке с типами
потом компилятор (препроцессор на самом деле) делает б-ж-ж-ж-ж и на выходе получается код преобразованный из typescript в javascript.можно сделать с растом так же. на входе rust с исключениями, в котором развёрнуты под капот все конструкции Result<T,E> а на выходе обычный rust. как-то так.
Kanut
14.01.2023 23:27Вот например у меня система плагинов. Каждый плагин должен имплементировать интерфейс. Но при этом какой из плагинов будет использован будет известно только после запуска программы. Более того в теории во время работы программы одни плагины могут быть заменены на другие. Плюс отдельные плагины могут быть созданы и после реализа самой программы.
Как в таком сценарии должен работать ваш препроцессор?
ednersky Автор
14.01.2023 23:33вот проект который делает джаваскриптер
у него три файла file1.ts, file2.ts, file3.ts — на тайпскрипте
а ещё два file4.js и file5.js на джаваскриптеперед запуском всё конвертится в js
точтак и с растом
main.rs — обычный раст
foo.rse — раст с исключениями из которого препроцессор перед компиляцией сгенерит foo.rs — обычный раст, как-то так можно сделатьи для голанг тоже самое
Kanut
14.01.2023 23:39Я всё ещё не вижу ответа на мой вопрос.
То есть смотрите вы скомпилировали программу и отослали её клиенту. А он сам пишет плагины под нужные интерфейсы.
Откуда препроцессор, который вы использовали для создания вашей программы, должен знать что там ваш клиент напихает в свои плагины? Ну то есть откуда ему знать будут в плагинах бросаться какие-то исключения или нет?
Единственный вариант, который я вижу это обязательное указание исключений в сигнатурах интерфейса. Да и то может такое быть что в сигнатуре исключение указано, а на самом деле его не будет.
ednersky Автор
14.01.2023 23:42мы говорим о препроцессоре, сворачивающем Result<T,E>
какая разница плагин там или еще что? достаточно сигнатуры функции
Kanut
14.01.2023 23:46Что в данном случае значит "сигнатура функции"?
Вы вот выше написали:
Кем помечена? человеком? плевать на его пометки, их будет расставлять препроцессор
Сигнатура конкретной имплементация? Так она препроцессору неизвестна потому что ещё не существует.
Сигнатура интерфейса? Так а его разве препроцессор пишет?
ednersky Автор
15.01.2023 00:10Что в данном случае значит "сигнатура функции"?
когда компилятор готовит объекты для рантайм связывания, то он генерирует для каждой функции их сигнатуры.
я возможно термином из другого языка оперирую, в расте я ещё не разбирался как это называется.
сигнатура это нечто, в машиночитаемой форме описывающее
- имя функции
- возвращаемое значение (тип)
- аргументы (количество, типы, иногда — имена)
без знаний этих параметров вы не сможете соединить два разных куска кода друг с другом.
иногда достаточно имён, но в случае с Растом — к гадалке не ходи — будет вся эта инфапосмотрите
nm target/debug/<ваш файл>|grep Resultнапример
Kanut
15.01.2023 00:19Извините, а вы вообще когда-то в своей работе имели дело с интерфейсами? И если да, то можете мне объяснить как препроцессор должен создавать сигнатуры интерфейсов? Или как компилятор должен их генерировать?
Или давайте ещё проще: вот я компилирую у себя кусок кода и мой клиент в то же самое время компилирует у себя кусок кода. Как нам сделать так чтобы потом эти два куска кода можно было "соединить"? Ну то есть чтобы сигнатуры совпали?
ednersky Автор
15.01.2023 00:29Извините, а вы вообще когда-то в своей работе имели дело с интерфейсами? И если да, то можете мне объяснить как препроцессор должен создавать сигнатуры интерфейсов? Или как компилятор должен их генерировать?
как компилятор компилирует вызов функции из другой библиотеки?
допустим пока нет препроцессора.
вот вы написали два проекта library.rs и main.rs который чем-то из library.rs пользуется.
в library.rs допустим есть функция
func foo(a: &String) -> Result<Foo, E>каким способом компилятор компилируя main.rs соединит всё это?
Kanut
15.01.2023 00:36каким способом компилятор компилируя main.rs соединит всё это?
При помощи того самого интерфейса. Который будет написан первым и в котором указаны все нужные функции с их сигнатурами.
Потом я беру этот интерфейс, пишу библиотеку с функциями которые его имплементируют и компилирую её.
И точно так же мой клиент берёт этот интерфейс и пишет код, который должен использовать эти функции. И компилирует его.
Более того если интерфейс известен, то кто угодно может писать сколько угодно библиотек, которые имплементируют этот интерфейс. И точно так же кто угодно может писать кучу разного кода, который потом будет использовать эти библиотеки.
Вы действительно никогда не работали с интерфейсами?
ednersky Автор
15.01.2023 00:39При помощи того самого интерфейса
что мешает препроцессору пользоваться интерфейсом?
Kanut
15.01.2023 00:45Пользоваться? Ничего не мешает. Вот только создать или "пометить" его препроцессор не может в принципе. Это должен делать кто-то другой. А вы выше написали:
Кем помечена? человеком? плевать на его пометки, их будет расставлять препроцессор
Так как препроцессор должен расставлять пометки? И если это делает человек, то как гарантировать что он это сделает правильно?
ednersky Автор
15.01.2023 00:50Пользоваться? Ничего не мешает. Вот только создать или "пометить" его препроцессор не может в принципе.
почему не может?
имеется функция.
она возвращает Result<T,E>? да — идём налево, нет — идём направо
блок обработки этого Result<T,E> на более верхнем уровне справляется полностью (не делегирует E наверх)?
да — налево, нет — направовот и разметили
остаются функции (весьма редкие) принимающие функции в виде аргументов, на них либо забить либо решить одним из предложенных выше способами
для Раста, кстати, как типизированного языка, две копии функции будут хорошо работать.
Kanut
15.01.2023 00:59Почему не может?
Потому что интерфейс есть, а кода к нему ещё нет.
имеется функция.
Откуда она взялась? Сначала пишется интерфейс и раздаётся всем. После этого кто угодно может писать разные варианты имплементации этого интерфейса. Или не писать.
И например тот, кто собирается использовать эту функцию, свой код написал раньше чем хотя бы один вариант имплементации этой функции был написан. Откуда его препроцессор должен знать будут там исключитения или нет?
ednersky Автор
15.01.2023 01:04Потому что интерфейс есть, а кода к нему ещё нет.
в интерфейсе написано Result? Да? нужно оформлять как исключение
Нет? не нужно оформлять как исключение
Kanut
15.01.2023 01:10То есть всё-таки "пометки" должен делать человек и препроцессор один с этим не справится. Отлично с этим пунктом мы разобрались.
Теперь следующий пункт: как гарантировать что человек всё сделает правильно? А не будет например так что в сигнатура функции написано что исключений быть не должно, а кто-то внутри использует функцию/библиотеку которая их бросает? Или наоборот что в сигнатуре указано что исключения возможны, а в коде не используется ничего что может их бросать?
ednersky Автор
15.01.2023 01:12То есть всё-таки "пометки" должен делать человек и препроцессор один с этим не справится
справится, просто в случае с препроцессором пометок человек будет делать на два порядка меньше
пометками будут факты применения операторов выброса исключения и его ловли.
а всё остальное может быть авторазмечено
Kanut
15.01.2023 01:17справится
Как? Вот вам интерфейс с сигнатурой функции: "bool IsTrue()".
Можете дать мне пример препроцессора, который по этой информации может сказать будет эта функция бросать исключения или нет?
пометками будут факты применения операторов выброса исключения и его ловли.
Какие "факты применения"? У вас есть интерфейс и всё. Кода ещё нет. Откуда ваши "факты применения возьмутся"?
У меня всё больше и больше растёт подозрение что с интерфейсами вы никогда не работали...
ednersky Автор
15.01.2023 01:22Как? Вот вам интерфейс с сигнатурой функции: "bool IsTrue()".
не бросает исключения. чего проще-то?
напомню: интерфейс — это уже то что ПОСЛЕ препроцессора получилось (если он использовался)
Какие "факты применения"?
обычные: пользователь написал
try-catch— значит здесь есть обработчик — факт
пользователь написал throw/raise — значит здесь есть генерация ошибки — второй факт
Kanut
15.01.2023 01:28+1не бросает исключения. чего проще-то?
Нет, бросает. Потому что я возьму и так напишу эту функцию.
напомню: интерфейс — это уже то что ПОСЛЕ препроцессора получилось (если он использовался)
Давайте я вам ещё раз напишу: интерфейс это то, что создаётся в первую очередь. Это контракт. О нём сначала договариваются, а потом уже кто-то начинает писать код.
пользователь написал try-catch — значит здесь есть обработчик —
Пользователь ещё вообще ничего не написал. Он может начать что-то писать только после того как вы дадите ему интерфейс.
И я теперь понимаю что вы точно никогда не работали с интерфейсами...
ednersky Автор
15.01.2023 01:35Нет, бросает.
нет не бросает. Потому что с исключениями там будет не bool а Result<bool, Error>
Kanut
15.01.2023 01:38Ну да, если я это туда напишу. А если забуду, то останется bool, а исключения всё равно будут.
Как ваш препроцессор должен там написать Result<bool, Error> если он не видит мой код?
ednersky Автор
15.01.2023 01:40Ну да, если я это туда напишу. А если забуду, то останется bool, а исключения всё равно будут.
если вы что-то забываете то раст перестаёт компилировать и напоминает.
я не понимаю, вы последовательными мессаджами издеваться пытаетесь или правда в непонимающего играете?
Kanut
15.01.2023 01:45Я не понимаю как в расте или где-то ещё ваш "препроцессор" должен ставить какие-то "пометки" в интерфейс если кода под этот интерфейс ещё не существует.
ednersky Автор
15.01.2023 01:47если интерфейса ещё не существует, то что вы о нём так печётесь? напишите его и только после этого выясняйте список проблем, который можно составить.
при написании интерфейса так же можно использовать препроцессор расставляющий Result где нужно и не ставящий там где это не требуется
Kanut
15.01.2023 01:53если интерфейса ещё не существует, то что вы о нём так печётесь?
Например потому что несколько команд или даже фирм одновременно начинают работать над чем-то, где этот интерфейс используется. Они не могут параллельно создавать свои варианты этого интерфейса. Он должен быть общим для всех.
То есть ладно вы с интерфейсами никогда не работали. Но это же базовые вещи. Неужели сейчас этому не учат?
при написании интерфейса так же можно использовать препроцессор расставляющий Result где нужно и не ставящий там где это не требуется
Так а откуда этот препроцессор должен знать где требуется, а где нет? Кода то ещё нет. Рэндомно ставить?
ednersky Автор
15.01.2023 01:57Так а откуда этот препроцессор должен знать где требуется, а где нет? Кода то ещё нет. Рэндомно ставить?
брать из интерфейса. если там Result проставлен — обрабатывать ошибку, нет — нет.
если вы там рандомно ставите Result, то препроцессор, так же как и компилятор Rust будет соответствующе реагировать.
я вообще не понимаю ваших последних сентенций
Kanut
15.01.2023 02:01Вы издеваетесь? Как препроцессор должен одновременно брать ваши "пометки" из интерфейса сам же их туда прописывать? Вы же пишите:
при написании интерфейса так же можно использовать препроцессор расставляющий Result где нужно и не ставящий там где это не требуется
Как препроцессор должен это делать если кода нет?
ednersky Автор
15.01.2023 02:05Вы издеваетесь?
мне кажется — вы
Как препроцессор должен одновременно брать ваши "пометки" из интерфейса сам же их туда прописывать?
брать и прописывать
Вы же пишите:
вас не учили что есть такие утилиты, как, например make? вы никогда не слышали, что когда собирают целое из зависимых друг от друга вещей, то сперва строят граф зависимостей и затем обходят его так, чтобы при построении зависящего, зависимости уже были простроены?
нет?
неужели теперь такому уже не учат? (ц) Kanut
Kanut
15.01.2023 02:14брать и прописывать
На основании какой информации?
вас не учили что есть такие утилиты, как, например make?
Нет, меня не учили что при помощи утилит вроде make можно генерировать интерфейсы с чистого листа. Не расскажите как это должно работать?
вы никогда не слышали, что когда собирают целое из зависимых друг от друга вещей, то сперва строят граф зависимостей
Конечно слышал. Вот только это работает исключительно если все эти части уже готовы и имеются в наличии. А их сначала надо написать. И интерфейсы кто-то должен прописать до того как вы что-то там начнёте собирать. И даже до того как вы начнёте работать над имплементацией этих ваших "зависимостей".
ednersky Автор
15.01.2023 02:17На основании какой информации?
- если на входе файл с расширением .rse, то на основе наличия try/catch/throw
- если на входе файл с расширением .rs, то на основе наличия Result<T,E>
чего проще-то?
Kanut
15.01.2023 02:20Так а откуда должны взяться эти ваши "файлы с расширениями"? Никаких файлов ещё нет. Мы на стадии создания общего контракта. Код ещё не написан.
ednersky Автор
15.01.2023 02:22Так а откуда должны взяться эти ваши "файлы с расширениями"? Никаких файлов ещё нет.
командная строка,
$ vim src/main.rs
ednersky Автор
15.01.2023 02:28это растовый файл, в нём препроцессор будет смотреть функции возвращающие Result
ednersky Автор
15.01.2023 02:34у вас пока пустой main.rs, вы ещё не решили что такое интерфейс. вроде недавно на лекции услышали, но тут всё разбилось о зависимости
Kanut
15.01.2023 02:36Если он пустой, то откуда там функции и на что тогда будет смотреть препроцессор?
ednersky Автор
15.01.2023 02:39в вашем случае — увидит пустой файл, выдаст на выходе такой же пустой.
это же препроцессор! вы чего-то ещё хотели? чтобы он за вас код написал? нет, он просто позволяет вам улучшить лаконичность: вместо 100500 символов напечатать 50250
Kanut
15.01.2023 11:38Я хотел бы чтобы он, как вы обещали, сам везде "пометил" исключения в нужных местах. Но он этого не может и следовательно как минимум в этом контексте он бесполезен...
ednersky Автор
15.01.2023 12:58он это может
просто крайняя фрагментарность мвшления (её причины отчасти рассмотрены в сиатье) мешает вам это понять
Kanut
15.01.2023 13:06Нет, не может. По крайней мере вы даже близко не можете объяснить как это должно работать в случае когда интерфейс создаётся раньше имплементации и потом не может быть изменён.
ednersky Автор
15.01.2023 02:21Нет, меня не учили что при помощи утилит вроде make можно генерировать интерфейсы с чистого листа. Не расскажите как это должно работать?
тот вопрос, что вы задали не был про генерацию интерфейсов, а про обработку зависимых друг от друга частей.
Конечно слышал. Вот только это работает исключительно если все эти части уже готовы и имеются в наличии. А их сначала надо написать.
ну дык напишите, сперва интерфейс.
Kanut
15.01.2023 02:24ну дык напишите, сперва интерфейс.
Отлично, написал. Но без "пометок" о исключениях. Как ваш препроцессор теперь будет эти пометки расставлять?
ednersky Автор
15.01.2023 02:27Отлично, написал
на расте написали? препроцессор по прописанным вами Result примет решение
на расте с исключениями? тогда интерфейс сперва получите пропустив его через препроцессор и возвращайтесь к предыдущему пункту
Kanut
15.01.2023 02:30Так а в чём тогда заключается "проставление меток препроцессором"? В том что он продублирует уже написанную мною информацию? Причём один в один? И зачем он тогда нужен? Всё равно уже всю работу я сделал. И при этом если я где-то ошибся, то он просто мои ошибки повторит...
ednersky Автор
15.01.2023 02:33Так а в чём тогда заключается "проставление меток препроцессором"?
вот у вас 20 функций с Result или без. все Result может проставить препроцессор на основе ровно одного места где вы обрабатываете ошибку и 17 мест где её генерируете
Kanut
15.01.2023 02:35Это ужк опять имплементация. Но поезд то уже ушёл. Интерфейс уже давно создан и всем разослан. Его уже не исправить.
0xd34df00d
15.01.2023 05:21Извините, а вы вообще когда-то в своей работе имели дело с интерфейсами?
По результатам этой и многих других дискуссий у меня сложилось впечатление, что ваш собеседник вообще ни с чем не имел дела на практике.
0xd34df00d
15.01.2023 05:20когда компилятор готовит объекты для рантайм связывания, то он генерирует для каждой функции их сигнатуры.
Это называется name mangling, и должно происходить только в тех языках, где допустима перегрузка функций. Сишка имена не манглит — ей не нужно, там перегрузки функций нет. Плюсы в блоке
extern "C"тоже не манглят.возвращаемое значение (тип)
Возвращаемый тип в мангленное имя не входит. Ну или найдите мне его тут:
_Z3food.аргументы (количество, типы, иногда — имена)
Когда именно имена? Очень интересно стало.
ednersky Автор
14.01.2023 21:56Если функция возвращает Result<T,E>, то это можно читать как "может вернуть T, а может бросить исключение E".
именно так.
если функция содержит в своём коде оператор throw или raise (или какой выберем) то она может бросить исключение
далее рассматриваем функции которые она вызывает: если какая-либо из них может бросить исключение, то наша функция может бросить исключение
перехват исключений для простоты пока отбросим.
можно же таким образом без участия пользователя разметить "бросает исключение/нет"?
amishaa
14.01.2023 22:04Нет, нельзя. И на это есть две существенные причины:
Во-первых, нелокальность - такая разметка требует всей кодовой базы (и, например, для библиотеки, в которой используются коллбеки, вообще невозможна). А компиляторы очень любят локальность (например, растовский лайфтайм - это локальное свойство, которое нужно проверять только внутри каждой функции - если контракты на всех вызовах выполняются, то и глобально выполняются)
Во-вторых, функции высшего порядка. Функция, которая берёт другую функцию как параметр должна каким-то образом уметь понимать, нужно ли ей проверять наличие эксепшенов или нет.
ednersky Автор
14.01.2023 22:25-1Во-первых, нелокальность — такая разметка требует всей кодовой базы
- почему нельзя библиотеки размечать?
- если говорить о препроцессоре, то почему нельзя библиотеки размечать по сигнатуре Result<T,E>?
А компиляторы очень любят
не компиляторы, а их писатели. любят чтобы было попроще.
а ещё писатели линтеров. и пускают поветрия "вы лучше сами помучайтесь, чем мы за/для вас что-то поделаем"Во-вторых, функции высшего порядка. Функция, которая берёт другую функцию как параметр должна каким-то образом уметь понимать, нужно ли ей проверять наличие эксепшенов или нет.
во первых решабелен и этот вопрос
во вторых даже если тупо отказаться от его решения (снизив эффективность) — это будет незначительное в общем снижение эффективности — плата за ЗНАЧИТЕЛЬНОЕ повышение читабельности кода
amishaa
15.01.2023 00:09почему нельзя библиотеки размечать?
если говорить о препроцессоре, то почему нельзя библиотеки размечать по сигнатуре Result<T,E>?
Размечать людьми или автоматически? Проблема с функциями бОльшего порядка остаётся, если автоматически. А если руками, то нужно уметь каким-то образом сказать, что можно передавать в качестве аргументов только функции не бросающие исключения. Как это предлагается делать?
не компиляторы, а их писатели. любят чтобы было попроще.
а ещё писатели линтеров. и пускают поветрия "вы лучше сами помучайтесь, чем мы за/для вас что-то поделаем"Любые операции на всей кодовой базе - это сложно и дорого. Например, исчезает инкрементальная компиляция.
во вторых даже если тупо отказаться от его решения (снизив эффективность)
Если размечать автоматически, то эффективность снижается не локально, а глобально - теперь любая функция, которая вызывает нашу функцию большего порядка, тоже размечена как бросающая эксепшен.
ednersky Автор
15.01.2023 00:13> Если размечать автоматически, то эффективность снижается не локально, а глобально — теперь любая функция, которая вызывает нашу функцию большего порядка, тоже размечена как бросающая эксепшен.
блин да почему же?
amishaa
15.01.2023 00:22По правилам разметки. Функция, которая не бросает исключения, не может вызывать функцию, которая бросает.
Если функция большего порядка всегда помечена как бросающая исключения (вне зависимости от переданных параметров), то свойство "может выбросить исключение" "заражает" все функции, которые её вызывают и далее вверх по стеку вызовов.
BugM
15.01.2023 00:28Вы же понимаете к чему это приведет? Можно сразу писать что все бросает исключение и закрыть тему.
Небосающие куски будут вроде noexept. Редко и аккуратно.
amishaa
15.01.2023 00:39Да. И в итоге всё будет равномерно медленно. Я же ровно об этом. Есть три варианта:
Вызовы дешёвые везде, но обработка исключений дорогая
Вызовы везде дорогие, зато исключения обрабатываются без дополнительных расходов
Вызовы в местах, где могут быть исправимые ошибки дорогие, где таких ошибок быть не может - дешёвые, обработка исключений дешёвая.
Первый вариант - это классические языки с эксепшенами. Вторым вариантом никто не пользуется, потому что слишком дорого для каждого вызова что-то такое делать.
Третий вариант реализован в расте и го.
ednersky Автор
15.01.2023 00:43Третий вариант реализован в расте и го.
в расте и го этого варианта нет. ибо исключений в этих языках нет
amishaa
15.01.2023 00:47Растовский Result<T,E> является прямым аналогом значения типа T либо исключения типа E.
Если мы договорились, что каким-то образом по сигнатуре функции нужно уметь понимать, какие эксепшены она вызывает, то дальше это вопрос синтаксический, а не содержательный.Какую задачу можно решить эксепшенами (при этом, как мы договорились, checked), но нельзя Result?
ednersky Автор
15.01.2023 00:52Какую задачу можно решить эксепшенами (при этом, как мы договорились, checked), но нельзя Result?
лаконичность. восстановления утраченного KISS-принципа
amishaa
15.01.2023 00:56В каком месте символ "?" не является лаконичным? Вызови функцию, если она может выбросить эксепшен, но ты не планируешь обрабатывать его сейчас - одним символом он пробрасывается выше. То, что тип Result нужно писать программисту руками, а никакой пре-процессинг этого сделать не может, вы обсуждаете в соседнем треде.
ednersky Автор
15.01.2023 01:08В каком месте символ "?" не является лаконичным?
в неуниверсальном
берём например YamlLoader из раст-ямль
и fs::read_to_string из stdв одной функции сперва читаем ямль с диска, затем сплавляем ямль лоадеру YamlLoader::load_from_str
пробуем поставить вопросики и раст нас начинает насиловать:
- или рисуй enum двух разных типов error
- или откажись от вопросиков и обрабатывай на месте
и то и то геморрой, который мог бы быть скрыт под капотом, не испорти этот старый маразматик оба языка
amishaa
15.01.2023 01:35Либо указывайте явные типы ошибки (если это нужно), либо, если конкретный тип не важен - приводите к какому-нибудь общему (хоть к Box<dyn std::error::Error, но правильнее использовать уже упомянутые выше anyhow или thiserror).
ednersky Автор
15.01.2023 01:38да да, выполняйте разного рода секс-приседания.
это не про лаконичность.
amishaa
15.01.2023 01:45Если написать Result<T, Box<dyn std::error::Error>>, то вопросы начинают работать ровно так, как Вам хочется - любой тип ошибки (со стиранием типа) к нему приводится. Поймать конкретную ошибку становится нельзя, зато очень лаконично.
ednersky Автор
15.01.2023 00:42Можно сразу писать что все бросает исключение и закрыть тему.
это — причина популярности языков с типами. Лень работать над линтерами, потому рекомендованы типы.
но "можно сразу писать" != "нужно сразу писать"
BugM
15.01.2023 00:44А зачем делать что-то что не работает? Checked exceptions в Джаве попробовали. Не работает. Второй раз по тем же граблям точно ходить надо?
ednersky Автор
15.01.2023 00:53вот честно про Джаву не знаю ничего.
очень часто "здесь не получается не потому, что невозможно, а потому что здесь так сделано (и надо переделывать) что именно здесь невозможно"
BugM
15.01.2023 00:58+1Мейнстримный язык. Который попробовал заставить проверять исключения или явно их передавать выше по стеку. И это оказалось грандиозной ошибкой дизайна языка.
Перед тем как пытаться придумать что-то новое стоит узнать что уже сделали другие и что из этого получилось. Не знать такую большую и такую типичную историю, ну такое себе.
ednersky Автор
15.01.2023 01:10Мейнстримный язык
увы, я не знаю тонкостей. предположу что не получилось по очень разным причинам, а вот невозможности так сделать в причинах не было
0xd34df00d
15.01.2023 05:25+1Там полиморфизма по этим спискам экзепшонов не было, поэтому оно и было больно.
0xd34df00d
15.01.2023 05:24Редко и аккуратно.
И без проверки корректности компилятором. Ошибся — получи
std::terminate(или что там конкретно плюсы дёргают, когда noexcept-функция бросает).Хотел бы такую ерунду — писал бы на питоне.
BugM
15.01.2023 05:37Ну да. За суровую оптимизацию надо платить. Не надо ее использовать во всем обычном коде. Даже на Джаве я бы хотел такого. Аннотация "вот в этом методе мне не нужны проверки выхода за границу массива, если оно произошло нужно!!! уронить всю jvm с любой ошибкой" Буквально сотню строк на миллион таким я бы пометил. И это стоит того, я точно знаю. Авторы всяких интересных библиотек тоже порадуются.
На Питоне о таком не парятся вообще. Там бы разобраться почему вот эта строка там где ожидалось какое-то число неверно распозналась. И оно выстрелило в рантайме.
0xd34df00d
15.01.2023 05:42+1За суровую оптимизацию надо платить.
Здесь вы платите не за суровую оптимизацию, а за слабость и невыразительность языка. Нет никаких фундаментальных причин, по которым аннотации могли бы проверяться рекурсивно без false negatives и с легко обходимыми false positives, кроме совместимости с легаси-кодом, который не кидает, но nothrow-деклараций не имеет.
Аннотация "вот в этом методе мне не нужны проверки выхода за границу массива, если оно произошло можно уронить всю jvm с любой ошибкой"
Сделать эти проверки по максимуму статическими тоже никто не запрещает.
BugM
15.01.2023 15:16Это кто-то должен написать. С виду язык не запрещает так делать. Хороший код на тех же джава стримах доказано не имеет целых классов проблем. Я даже JEP правильно сформулировать не осилю. Увы.
А условный Хаскель или что-то такие оптимизации умеет?
У плюсов наследие и разнообразие такое что там так может и не выйдет.
ednersky Автор
15.01.2023 00:31По правилам разметки.
я потерял нить
что за правила разметки? кто размечает?
amishaa
15.01.2023 00:43Не важно, кто размечает компилятор/препроцессор/программист или высшие силы.
Если в разметке получилось так, что "не бросающая исключения функция" вызывает "бросающую исключения функцию" и не ловит её ошибку, то эта разметка некорректна.
Если мы все функции высшего порядка помечаем бросающими исключения, как Вы предлагаете вот в этом комментарии: https://habr.com/en/post/709328/#comment_25112510 то любая функция, которая её вызывает и не проверяет вызов на ошибку тоже должна быть помечена как бросающая исключение.
ednersky Автор
15.01.2023 00:46Если в разметке получилось так, что "не бросающая исключения функция" вызывает "бросающую исключения функцию" и не ловит её ошибку, то эта разметка некорректна.
согласен. это баг разметки, который требуется поправить
Если мы все функции высшего порядка помечаем бросающими исключения, как Вы предлагаете вот в этом комментарии
то дочитаем комментарий о том, что таких функций в коде встречается редко — это во первых (и это причина забить на эту просадку перфа)
и во вторых решабельна и задача по данной проблеме.
навскидку: две функции высшего порядка под капотом и рантайм свитч между ними в зависимости от…
тупое решение, но будет работать.можно рассмотреть и более изящные
amishaa
15.01.2023 00:54то дочитаем комментарий о том, что таких функций в коде встречается редко — это во первых (и это причина забить на эту просадку перфа)
Так проблема в том, что одна редкая функция где-то глубоко по стеку вызовов "заражает" все функции вверх по этому стеку.
и во вторых решабельна и задача по данной проблеме.
навскидку: две функции высшего порядка под капотом и рантайм свитч между ними в зависимости от…
Чтобы что-то подставлять в рантайме, нужны дополнительные расходы.
В расте это сделано на этапе компиляции - можно написать код с Generic-параметром, который работает и для функций Result (и тогда тоже возвращает Result), и для функций возвращающих примитивное значение (и тогда возвращает примитивное значение).
Во время компиляции будут создано несколько реализаций (по одной для каждого использованного типа) и на этапе компиляции будет подставлена правильная.
ednersky Автор
15.01.2023 01:03Чтобы что-то подставлять в рантайме, нужны дополнительные расходы.
вообще забейте на это
прототип функции, передаваемой в аргументы известен всегда.если принимается в аргументы Result<T,E> значит может бросать исключения, если нет — нет
это же раст. случаи где что-то не так — ошибка компиляции.
тьфу, мы обсуждаем то что и обсуждать не имеет смысла.
amishaa
15.01.2023 01:09+1В расте это ровно так и сделано. Я пытаюсь объяснить, почему это решение (растовское) невозможно реализовать сильно меньшей кровью. Откуда появляется необходимость явно указывать типы в Result, зачем обработка ошибок сделана (синтаксически) так, как сделана, а не иначе и т.д.
ednersky Автор
15.01.2023 01:10В расте это ровно так и сделано
в расте так не сделано. в расте исключений нет
gandjustas
15.01.2023 00:29Очевидный ответ - компилятор вставляет другой код.
gandjustas
15.01.2023 01:42Видимо есть соображения, которые вы не знаете или не понимаете. Вы же не считаете себя умнее тех кто создает языки и компиляторы?
ednersky Автор
15.01.2023 01:59ну вот я сходил по ссылке и увидел что в случае если включают мютексы на многопоточном коде на момент разворачивания ексепшена, то да, медленнее
но это НОВОЕ ПРОДУКТОВОЕ ТРЕБОВАНИЕ к обработчику ошибок. поскольку сейчас в расте и го таких требований нет, все отлично живут без этого, значит можно не замедляться.
gandjustas
15.01.2023 00:28Довольно сильное утверждение.
Почему никто до сих пор не сделал компилятор, который делает эксепшены более дешёвыми, чем существующие? Если это возможно за разумное время?
ednersky Автор
15.01.2023 00:33а что значит "никто не сделал"?
прям во всех-всех языках так?BugM
15.01.2023 00:34Я чуть выше вас уже просил привести пример такого языка. Желательно не совсем экзотического.
BugM
15.01.2023 00:48Плюсы вы серьезно? Там типичные очень дорогие исключения.
https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/
Питон сам по себе очень медленный. Там бесполезно что-то тестить на скорость. Не для скорости работу кода он сделан.
Про Перл увы ничего не знаю.
ednersky Автор
15.01.2023 00:59- я серьёзно
- по ссылке невалидный бенчмарк
сравнивается чистый return без проверок с ексепшеном в котором под капотом проверки, очевидно что будет разница
так же как в расте написать две функции
func foo() -> i32 func foo() -> Result<i32,Error>очевидно, что первая (В СОВОКУПНОСТИ) будет быстрее. почему?
во первых возвращает одно число
во вторых результат второй нужно пропускать через matchно мы говорим что если Result зачем-то есть, значит эту звезду зажгли потому что так нужно ведь?
BugM
15.01.2023 01:15+1Вот люди пишущие про стандарт. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html Результат тот же самый.
Наверно они понимают в бенчмарках?
ednersky Автор
15.01.2023 01:20если сравнивают так же как предыдущие — нет.
ещё раз: в предыдущем бенчмарке сравнивались исключения, включающие в себя
- возврат ошибки
- проверку того что она произошла
- поиск блока обработки
- передачу ошибки этому блоку
с
- просто возврат значения
в этом смысле исключения всегда будут медленнее.
но Result<T,E> — это первый вариант, а не второй. если побенчмарать
return T vs return<T,E> то удивительно, но второе тоже будет бенчмаркать хуже.но с этим живут?
а препроцессингом сфолдить такое до не худшей производительности вполне можно
BugM
15.01.2023 01:35Вторая ссылка это текст предложения в стандарт плюсов. Вы абсолютно точно уверены что там бенчмарк неверно написан?
Почему исключения сделаны именно так дорого, а не иначе дешево это другой вопрос. Пока стоит остановиться на том факте что исключения во всех типовых языках это очень дорогая операция. И видимо есть глобальные причины почему это так. Потом можно будет продолжить выяснять что это за причины.
ednersky Автор
15.01.2023 01:39Вторая ссылка это текст предложения в стандарт плюсов. Вы абсолютно точно уверены что там бенчмарк неверно написан?
я не могу увидеть что там во второй ссылке за бенчмарки, у меня этот сайт так криво отображается, что меню закрывает большую часть текста. ХЗ почему так, видимо надо написать вторую статью про то "что они сделали со фронтендом" :)
BugM
15.01.2023 01:55Вам точно стоит что-то сделать со своим компом чтобы сайт с предложениями в стандарт плюсов у вас работал. Это довольно основополагающая штука вообще. Особенно для дискуссии про реализацию языковых фич.
ednersky Автор
15.01.2023 02:00я сделал, ниже есть мой отчёт (просто сайт не приспособлен к маленьким экранчикам)
ednersky Автор
15.01.2023 01:55сумел таки продраться к тексту.
The root cause is that the unwinder grabs a global mutex to protect the unwinding tables from concurrent changes from shared libraries.
в обсуждаемом нами вопросе такого быть не может, ибо проверки Result<T,E> не ставят мютексы
BugM
15.01.2023 02:08И вы получаете Go'шный результат. Где разработчик обязан писать бойлерплейт после каждой функции. За редкими-редкими исключениями.
Это другой результат, но есть сомнения в том что он лучше.
amishaa
15.01.2023 02:19+1Нет, конечно. Можно пример if err != nil в каком-нибудь достаточно известном проекте на расте?
ednersky Автор
15.01.2023 02:24Можно пример if err != nil в каком-нибудь достаточно известном проекте на расте?
дык
match result {… =>… }
это вот прямо тот же самый if
amishaa
15.01.2023 02:31match result - это, скорее, аналог try/catch блока, если с err что-то происходит.
А если ошибку нужно просто пробросить, то в расте бойлерплейт не нужен.
ednersky Автор
15.01.2023 02:35match — просто набор if'ов ничего более
А если ошибку нужно просто пробросить, то в расте бойлерплейт не нужен.
выше пример где нужен (ямль + std error)
amishaa
15.01.2023 02:49выше пример где нужен (ямль + std error)
Где бойлерплейт вот в этом решении: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6786c5d8cc73f485c0a6780a01b229d4 ?
amishaa
15.01.2023 13:20Простите, вечером прислал не ту ссылку.
Вот правильная ссылка: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2662fec2621b9d9f65660649551d21ff
Объединят, как и ожидалось, std::io::Error и yaml::scanner::ScanError без дополнительных усилий.
amishaa
15.01.2023 01:42Это будет медленно там, где есть Result и быстро там, где его нет. При этом там где он есть, проход по ошибке будет примерно так же быстр, как и проход без неё.
amishaa
15.01.2023 01:49Не может, мы это обсуждали уже. Потому что, например, у колбеков тип "возвращает int32" и "возвращает Result<int32, IOError>" - это два разных типа (после препроцессора, но не до!) и возникает проблема с функциями высшего порядка.
ednersky Автор
15.01.2023 02:02-1не возникает, разобрали уже.
типы не дадут в один колбек запихивать два разных варианта, а если всё же хочется — придётся enum лепить.
так что здесь не то, что нерешаемых, вообще никаких проблем нет
amishaa
15.01.2023 02:07Enum - это плохое решение, потому что если в функцию можно запихнуть возвращающий E-вариант callback, то функция должна сама уметь возвращать exception (и тогда её нужно пометить как бросающую эксепшен).
Есть возможность сделать два варианта функции с колбеком - когда на входе колбек не бросает и функция сама по себе не бросает, и вариант для колбеков, которые бросают.
Если выбор функции случается автоматически (без участия человека), появляется проблема с тем, что выбраться не та, которую ожидал человек и всё станет катастрофически медленнее.
ednersky Автор
15.01.2023 02:12Если выбор функции случается автоматически (без участия человека), появляется проблема с тем, что выбраться не та, которую ожидал человек
не появляется. поскольку на стадии компиляции однозначно понятно какая куда
amishaa
15.01.2023 02:18Так это, собственно, задача прописывания типов. Если типы прописаны (напрямую или с помощью дженериков) - понятно. Если не прописаны - непонятно.
ednersky Автор
15.01.2023 02:26пользователь оперирует типами идущему по mainflow, а препроцессор заглядывает есть ли errorflow (факт использования throw) и расставляет Result или нет.
amishaa
15.01.2023 02:30Если типы только по mainflow и никакой обработки (try-except) в коде нет, то Result вообще не нужны, сегодняшний rust так тоже умеет, достаточно писать unwrap.
Если какая-то обработка ошибок всё-таки ожидается, то как они должны меняться?
ednersky Автор
15.01.2023 02:36достаточно писать unwrap.
unwrap — это panic
unwrap — это снижение лаконичности
amishaa
15.01.2023 02:41Так эксепшены без try-блоков неотличимы по поведению от паники, разве нет?
Лаконичность теряется только в взаимодействии с другими библиотеками, и, естественным образом, делается один раз на каждую функцию максимум (при этом не один раз в каждом проекте, а прямо глобально один раз).
ednersky Автор
15.01.2023 09:48Так эксепшены без try-блоков неотличимы по поведению от паники, разве нет?
и? каким это тут боком?
Лаконичность теряется только в взаимодействии с другими библиотеками
в каждой первой функции не нужно
- возиться с вопросами unwrap, match, или расставлением вопросиков
- врапать возвращаемые значения в Ok/Some/Err/итп
amishaa
15.01.2023 13:12Вопросики нужны только для функций, которые могут возвращать ошибочное значение. Для тех, которые не могут возвращать (при этом и вызываемая функция может не возвращать, и вызывающая, достаточно любого одного) вопросики писать не нужно.
В традиционных исключениях тоже нужно писать два разных слова return и throw, чтобы отличать основной путь выполнения и ошибочный. Если так не нравится писать Ok/Err никто не мешает себе завести макрос throw!, заворачивающий в Err, и retur!, заворачивающий в Ok.
0xd34df00d
15.01.2023 05:28В этом треде уже вспоминали, что задача полного type inference в общем случае для достаточно мощных систем типов (коей растовская тоже является, насколько я её понимаю) неразрешима?
amishaa
15.01.2023 05:46Растовская - точно не разрешима, она тьюринг-полная: https://sdleffler.github.io/RustTypeSystemTuringComplete/
0xd34df00d
15.01.2023 05:59Пользуясь случаем, передаю привет ChatGPT и выражаю уверенность, что людей она заменит нескоро, хотя, казалось бы
amishaa
15.01.2023 06:03Потому что проблема останова неразрешима. В тьюринг-полной системе эту задачу (для конкретной машины на конкретном входе) можно (вычислимо) сформулировать, что даёт сведение.
0xd34df00d
15.01.2023 06:07Да, я это понимаю, но «вывести тип этого терма» и «определить, эквивалентен ли этот тип тому типу» — это две разные задачи, и свести одну к другой у меня сходу не получилось без некоторых дополнительных предположений о системе типов.
amishaa
15.01.2023 13:42Ну конкретно растовская, вроде, с равенством (есть трейт EQ<P,Q> который реализуем только EQ<T,T>). Возможно, достаточно потребовать даже что-то более слабое (или даже ничего), сходу действительно не очевидно.
Inspector-Due
15.01.2023 21:27К слову о ChatGPT
Похоже, она подходит лишь для того, чтобы эссе написать, а так она выдаёт такое:
А также, захотев разобраться с тем, что такое Post's lattice, я получил "also known as the Post canonical system..."
В общем, пора перебираться в математики, чтобы нейросеть не могла заменить меня (любителя перекладывать джейсончики и байтики)
gandjustas
15.01.2023 01:44То и значит - никто не сделал, никто. Вообще никто ни в одном из языков, на которых пишет кто-то кроме автора языка.
Да, прям во всех, на которых пишет кто-то кроме автора языка.
Найдете контрпример - можем продолжить диалог.
ednersky Автор
15.01.2023 01:45что значит никто? в C++ прекрасные исключения. очень быстрые.
Result<T,E> раста не быстрее throw C++
amishaa
15.01.2023 01:50+1Для кода, который не может бросать эксепшены - настолько же быстрый.
Для кода, который может бросать, но не бросает - да, чуть медленнее C++.
Для кода, который может бросать и бросает - быстрее C++.
gandjustas
15.01.2023 01:57+2Наверное потому что исключения в C++ настолько быстрые придумали даже ключевое слово nothrow, которое в рамках метода убирает супер-быстрые исключения, которые ничего не стоят.
Как быстро работает Result<T,E> раста по сравнению с throw C++ - пришлите ссылку на бенчмарк.
ednersky Автор
15.01.2023 02:09и likely unlikely тоже придумали. С/С++ — вообще язык где можно много чего пооптимизировать/поэкономить, да.
gandjustas
15.01.2023 00:22Ну конечно же это не так. Вы легко найдете бенчмарки на любом языке с исключениями и составите понимание их стоимости.
Я сначала даже удивился насколько дорогие исключения в .NET например.
Видимо компилятор вставляет гораздо больше кода для обработки исключений, чем вы привели. Как минимум нужен код для получения stack trace при выбрасывании.
ednersky Автор
15.01.2023 00:36Как минимум нужен код для получения stack trace при выбрасывании.
- стектрейс нужен в debug режиме
- для каждой ошибки он статичен, а потому стектрейсы тоже можно составлять на этапе компиляции (то есть не тратить время в рантайме): компилятору в общем случае всегда известно на сколько уровней поднимется по стеку эта ошибка или та до её перехвата
Я сначала даже удивился насколько дорогие исключения в .NET например.
а в Perl, например, они были весьма дёшевы.
BugM
15.01.2023 00:49+2стектрейс нужен в debug режиме
Он как раз в проде нужен. Чтобы по сообщению в логе понять где упало.
для каждой ошибки он статичен, а потому стектрейсы тоже можно составлять на этапе компиляции (то есть не тратить время в рантайме): компилятору в общем случае всегда известно на сколько уровней поднимется по стеку эта ошибка или та до её перехвата
А-ха-ха. Падает какое-нибудь чтение из файлика. Вы уверены что путь вызова всегда один?
ednersky Автор
15.01.2023 01:37Он как раз в проде нужен.
нет, он не нужен в проде совершенно.
вы сейчас отлично без него обходитесь, Result<T,E> может включать способы манипуляции стектрейсами, однако не включает.
следовательно и далее обойдётесь.
продуктовое требование "хочу стектрейс" однозначно требует за него заплатить
говорить же "меня устраивают ошибки" vs "если ошибки будут через синтаксис исключений, то мне обязательно нужен стектрейс" — это признак биполярного расстройства
amishaa
15.01.2023 01:47Зависит от E. Есть стандартные решения, которые в E записывают stacktrace (например, уже упомянутый anyhow по умолчанию пишет трейс).
ednersky Автор
15.01.2023 02:13решения есть, но если их начать бенчмаркать с простыми Result<T,E>, то сюрприз: окажется что они бенчмаркают хуже
amishaa
15.01.2023 02:20До тех пор, пока эксепшены не случаются - они стоят столько же.
В тот момент когда случаются - да, за наличие трейса нужно платить, это, вроде, ожидаемо.ednersky Автор
15.01.2023 02:29трейс — дополнительное продуктовое требование.
если он нужен — за него платим
если он не нужен — его не формируем и всё бесплатно
ednersky Автор
15.01.2023 02:39бесплатность измеряем относительно растового Result<T,E>
тут именно бесплатно получится
amishaa
15.01.2023 02:51Бесплатность нужно сравнивать относительно T.
Если бы мы были готовы (по производительности) жить в мире, где любая функция может вернуть result, были бы более холиварные вопросы типизации.
ednersky Автор
15.01.2023 09:52Бесплатность нужно сравнивать относительно T.
ни в коем случае. бесплатность сравнивается с иными решениями тех же продуктовых требований.
а с T можно сравнивать только в одном случае, если можно доказать что те же продуктовые требования возможно реализовать с такими же затратами как T
amishaa
15.01.2023 13:39Подождите, откуда в этой ветке берутся продуктовые требования? Мы же обсуждали требования к дизайну языка, или, точнее, к дизайну исключений в компиляторе.
BugM
15.01.2023 01:52вы сейчас отлично без него обходитесь,
Я временами на Джаве пишу. Стектрейсы в исключениях это великолепно. Они облегачют дебаг значительной части ошибок прям на порядок.
продуктовое требование "хочу стектрейс" однозначно требует за него заплатить
Это свойство языка. Поменять после первого релиза уже нельзя. Подумайте еще раз. И заодно посмотрите как у других сделано. Есть более одного решения. И почему сделано так а не иначе тоже почитать стоит. И заодно к чему эти решения привели в итоге тоже почитать стоит. Неглупые люди эти решения придумывали и неглупые люди годами или пользуются.
говорить же "меня устраивают ошибки" vs "если ошибки будут через синтаксис исключений, то мне обязательно нужен стектрейс" — это признак биполярного расстройства
У всех решений есть свои особенности. Надо просто знать их и уметь ими правильно пользоваться. Общего решения хорошего для всего тут нет.
gandjustas
15.01.2023 04:54+2Стоп. Я видимо был слишком уставший и голодный когда писал коммент, на который вы ответили, что даже не понял очевидную ошибку в ваших рассуждениях.
Если предположить что есть гипотетический компилятор Rust или Go, который автоматически превращает код вида
x = foo()в код вида
x, err = foo() if (err) { return _, err}То такой компилятор сделает в разы более медленный код, чем существующий компилятор Rust или Go. По сути мы добавляем к каждому вызову функции проверку на 0 и условный переход вперед. Даже в том случае если ошибка никогда не происходит.
Особенно все плохо становится если вызовы функций вложенные:
func f1() { f2() } func f2() { f3() } // ... func f1000000() { f1000001() } func f1000001() { x = x+1 }Ваш гипотетический компилятор родит 1000000 проверок одно присваивание.
Возможно первые компиляторы С++ делали так, но давно канули в лету. Современные компиляторы конечно же такого не делают и никогда не будут делать.
------------
В современных компиляторах код, который не выбрасывает исключений не платит почти ничего. Всего лишь для каждого try надо поместить в список обработчиков (обычный связный список) ссылки на блоки кода catch и finally + указатель стека + адрес продолжения, а при выходе из try - удалить. Список односвязный, добавление имеет сложность О(1).
За все платит тот кто обрабатывает исключения.
В этом случае возникновения исключения надо (в архитектуре x86):
Создать объект исключения (аллокация). Пока даже не рассматриваем вопрос получения stacktrace.
-
Идти по списку и выполнять блоки finally (эпилоги функций) , пока не встретится подходящий catch.
Проверить тип блока
Если это catch, то проверить условия срабатывания - typecheck (получение vtbl и поиск по таблице типов, рекурсивно) + guards для C#
-
Выполнение блока:
Вернуть стек к той функции, которая поставила обработчик (одно присваивание EIP)
Переход к блоку обработки.
Вернуться к коду\следующему блоку finally, восстановить EIP
Удалить из списка обработчиков блок
Удалить объект исключения (для C++) если был catch
Для C++ вообще все плохо так как почти везде автоматическая деструкция, поэтому почти везде добавляется обработчик эпилога в список. nothrow придумано было как раз чтобы убрать эту операцию.
Если не брать stacktrace и сложный поиск совпадения обработчика по таблице типов, то описанные действия - всего пара десятков операций. Но эти пара десятков могут оказаться больше самой функции, в которой происходит исключение.
------------
для каждой ошибки он статичен, а потому стектрейсы тоже можно составлять на этапе компиляции (то есть не тратить время в рантайме): компилятору в общем случае всегда известно на сколько уровней поднимется по стеку эта ошибка или та до её перехвата
Ну это просто неверно. Предположим вы делаете парсер. Классический такой, с визиторами по GOF. Как может компилятор вычислить насколько вверх по стеку поднимется ошибка?
ednersky Автор
15.01.2023 09:56Для C++ вообще все плохо так как почти везде автоматическая деструкция, поэтому почти везде добавляется обработчик эпилога в список
дык в расте обработчик эпилога ваяет сам разработчик в каждой первой функции
от С++ тут отличия только в том, что разработчик среднестатистически более низкоквалифицирован, нежели разработчик компилятора, а потому, следовательно, в среднем, перегруженная на него функциональность имеет худший перф, нежели не перегруженная
gandjustas
15.01.2023 19:11Не очень понимаю о чем вы.
При отказе от выбрасывания исключений мы не платим ни за блоки try, ни за перехват исключений. Вместо этого нам предлагается в часть методов прописать явную обработку кодов возврата. Пролог и эпилог функций не меняется.
У кодов возврата есть две проблемы: многословная проверка и возможность эти коды игнорить.
В Расте обе проблемы решены: атрибут
#[must_use]не позволяет игнорироватьResut<T, Err>, а оператор?разворачивается вif Err { return Err }. В простых случаях с помощьюunwrapилиexpectможно грохнуть программу при ошибке, как в языке с исключениями при отсутствии их обработки.В Go мало того что обе проблемы не решены, так еще и коржеж (значение, ошибка) не является не является выражением, что отрезает возможность сделать как в Rust. Самое смешное, что в Go при этом всем есть обработка исключений через panic и recover.
ednersky Автор
15.01.2023 20:03> При отказе от выбрасывания исключений мы не платим ни за блоки try, ни за перехват исключений.
кто такие «мы»?
разработчики приложений на этом языке продолжают платить, причём платить гораздо дороже.
раньше (в С++) они платили только флопсами
теперь, в плюс к флопсам, они платят своим временем, расставляя однотипные обработчики ошибок по всему коду, захламляя доступ к пониманию алгоритмов.
кроме того, ещё раз: поскольку среднестатистический разработчик на раст по квалификации ниже среднестатистического разработчика компилятора этого языка, то его реализация кода обработки ошибок в общем случае бенчмаркает хуже, чем если бы это было сделано централизовано.gandjustas
15.01.2023 20:10Разработчики не платят быстродействием программы.
кроме того, ещё раз: поскольку среднестатистический разработчик на раст по квалификации ниже среднестатистического разработчика компилятора этого языка, то его реализация кода обработки ошибок в общем случае бенчмаркает хуже, чем если бы это было сделано централизовано.
Опять не понимаю о чем речь. Можно пример того кода, который напишет среднестатистический разработчик Rust для обработки ошибок?
Я вижу два варианта: оператор
?и функцииunwrapиexcept. Что по вашему вызовет проблемы? И какие проблемы?ednersky Автор
15.01.2023 20:43> Я вижу два варианта: оператор? и функции unwrap и except. Что по вашему вызовет проблемы?
ещё есть match, ещё есть варианты if let итп
а проблемы вызовет любой способ, применённый неправильно, как-то, например, повторные проверки итп
постоянное конструирование/деконструирование объектов Result явно бенчмаркает хуже, чем если бы централизовано под них просто выделили ОДНАЖДЫ по переменной на тред
amishaa
15.01.2023 21:11Result - это не джавовский объект, под который нужно выделять много памяти, это просто enum с двумя возможными значениями. При этом, если хочется, его можно менять прямо на месте (и, в достаточно большом классе случаев, компилятор это даже за тебя делает).
amishaa
15.01.2023 21:20В случае, если оба типа в нём указатели, то про него можно думать как про код возврата (вернулся результат или ошибка) + указатель на соответствующий объект (в первом случае на результат, во втором на ошибку). И весь ? или if let - это проверка кода возврата.
ednersky Автор
15.01.2023 21:24про всякие оптимизации понятно, но централизованно всё это делать — совершенно точно можно было бы дать людям лаконичность, плюс лучший перф
amishaa
15.01.2023 21:31Можно подробнее что предлагается сделать?
Всегда проверять "код возврата"? Даже у функций, которые гарантированно не падают? Это будет дороже по перформансу.
ednersky Автор
15.01.2023 22:32тут выше подробнее 100 раз размяли уже.
проверять код возврата там где возвращаются ошибки (бросаются исключения), и не делать это когда они не возвращаются.
поскольку человек это всё равно делает, то компьютер и подавно справится
> Это будет дороже по перформансу
это будет дешевле по перфомансу, ибо будет писаться профи (и улучшаться со временем) а не каждый раз новым случайным разработчиком с нуля, пусть даже и копипастой со стековерфлоу
amishaa
15.01.2023 23:37Именно, что обсуждалось.
Компилятору нужна разметка, чтобы знать, где проверять (см. noexcept).
ednersky Автор
15.01.2023 23:40Для того, чтобы разметить у него всё есть. Абсолютно всё необходимое.
ednersky Автор
15.01.2023 23:42> см. noexcept
всякую задачу можно решить разными способами. Выбор способов иногда определяется легаси, обратной совместимостью итп.
Новый язык может обойтись без noexcept, но реализовывать исключения на базе механизма аналогичногоresult, errorголанга илиResultраста
amishaa
16.01.2023 00:17Так что Result, что result, error - это ручная разметка, а не что-то автоматическое. Если эта разметка уже делается руками, то Result выглядит хорошим решением - нельзя взять результат не проверив код возврата.
ednersky Автор
16.01.2023 00:26не, дело не в разметке а в способах реализации исключений.
и резалт и тапл с резалтом — это один и тот же способ
longjump — чуть более другой
FrolVII
14.01.2023 03:20+2Приятно читать человека, хорошо осмыслившего раскрываемый вопрос. Спасибо за статью.
В целом, я разделяю ваше отношение к процессам "разделения труда" и "отчуждения от результатов труда", а также к их следствиям для работников. Однако:
1) Утопия (просто используем этот термин для обозначения наших целей, не декларируя, при этом, их недостижимость) в рамках одной отдельно взятой отрасли - это "утопия в квадрате". Обычную утопию проще построить.
2) В описанной вами ситуации проблема не только в микросервисах, но еще и в догматизме. Создание монолита для одной лишь озвученной в истории задачи (в качестве исключения) не привело бы к разрушению "системы отчуждения от результатов труда", но спасло бы для бизнеса миллиарды. Догматизм плох и для другой стороны, к слову.
gandjustas
14.01.2023 04:15+4Одна из лучших статей на Хабр за всю историю его существования. И я не согласен с половиной того, что написано.
FrimInc
14.01.2023 12:10+5Хорошая статья, только на Маркса надо было ссылаться сразу в первом абзаце - чтобы сэкономить время читателя.
Daddy_Cool
14.01.2023 15:29+1Попробуем расставить точки над "Ё" в слове "марксизм".
1. Тяжелый, отупляющий труд - это плохо для рабочего.
2. Капиталист хочет этого, чтобы он мог заработать.
3. Скорее всего обществу в целом от этого будет лучше - больше качественных и дешевых товаров.
Выводы.
За тяжелый, отупляющий труд надо платить больше. За творческий и интересный - меньше. Тогда можно установить некий общественный баланс - художникам нужны рабочие на конвеере хотя бы чтобы последние штамповали кисти. При этом творческий и интересный труд может иметь отрицательную стоимость. Много музыкантов кто тратится на репетиции, инструменты, и т.п... выступает в клубах (создавая ценность для слушателей), и ничего на этом не зарабатывает. Или писатели с самлиба/самиздата. Или программисты создающие СПО.
Но! Эта стройная система начинает усложняться. Ибо экономическое принуждение - есть люди кто не может заниматься интересным и творческим трудом (по совокупности любых причин), и зачем этим людям платить больше если их можно заставить экономически (т.е. угрожая голодной смертью) работать на конвеере? Дальше (например) эти работники могут объединиться в профсоюзы, потребовать увеличения ЗП, и всё опять усложнится.
Видимо экономические модели потому плохо и работают, что много важных факторов действуют одновременно и результат не объясняется простыми моделями которые помещаются в голове. Т.е. надо писать систему уравнений и результат будет непредсказуем, особенно учитывая неустойчивости.im_last
15.01.2023 02:20Капитализм по определению не имел души.
А все что стремится к бездушному и сам лишает души.
А все что одухотворяет, эту душу как раз усиливает.
Автор рассказал об расчеловечевании, ибо нас как раз разчеловечивают и тот путь где вы стремитесь к тому, что бы быть лучшей версией себя - превращается в путь расчеловеченного нечто, но богатого и обеспеченного.
Люди умирают как люди, превращаясь в бездушных биороботов, которые, функционально, не сильно отличаются от тех программ, которые могут сами и писать.
gregorybednov
15.01.2023 02:28+1То, что Вы описываете как систему усложняющуюся (развивающейся или деградирующей), безусловно таковой действительно является - это фактическая абсолютная правда, с которой никто и спорить не будет (возможно, уточнять детали). Тем не менее, в дальнейших рассуждениях хотел бы уточнить.
Так вот, марксизм развивает диалектику Гегеля, постулируя: "усложняющиеся" (развивающиеся или деградирующие) "системы" (а точнее сказать, материи - общественная материя, биологическая, ..., так как усложняется именно сама материя) развиваются или деградируют в процессе противоречий и борьбы. Определить ключевой мотив борьбы, её "законы", и позволит определить тенденции развития (причем как "развивающие", так и "разрушающие"). Вернёмся к Вашему комментарию.
Выводы.
За тяжелый, отупляющий труд надо платить больше. За творческий и интересный - меньше. <...>Кому это надо? Пролетарию (наёмному работнику, продающему своё время и труд) или капиталисту (владельцу производства) - ведь он по п.2 по-прежнему существует? Или, может быть, подклассу мелкой буржуазии (люди, которые работают на своих средствах производства и сами же продают свои результаты труда на рынке)?
Классовая борьба - это как раз и есть борьба, выстроенная на неустранимом противоречии интересов, всю дорогу развивающая капиталистическое общество, всякое действие или бездействие в ней представляет интересы классов, и в борьбу вовлечено абсолютно всё общество, особенно государство.
Классовая борьба пролетариата породила те самые профсоюзы, выходные дни, нормированный рабочий день, усиленную оплату переработок и вредности, пенсии, а классовая борьба капиталистов отыграла, породила пенсионную реформу, ненормированный рабочий день, систему штрафов, а также даже всякие разные события, из-за которых люди вынуждены переселяться (из-за чего цены и заплаты меняются тоже не в пользу трудящихся), и так далее. Часть этих мер была выгодна даже капиталистам (например, нормированный рабочий день повышает эффективность труда, достойные условия труда также этому способствуют), но тут уже надо помнить, что они тоже между собой конкурируют, и очень сложно выжить как предприятие, имея под боком ничем не сдерживаемого конкурента-"людоеда" (а точнее, не одного, а очень много), который заставляет рабочих работать в адских условиях по 16+ часов в сутки, потом выбрасывает этих несчастных рабочих как отработанный материал, приплатив им скажем всего лишь в полтора раза больше, чем может позволить твоё "доброе" предприятие. Потому что в интересах капиталиста действовать таким образом (а будет ли он в ней действовать - его воля, и, к слову, его произвол), и решить это могут только наёмные работники (в чьих интересах, осознают они это или нет, как раз всё это "людоедство" ликвидировать), которые в отдельности несоотносимо слабее, но в целом оказывается, что на них всё и держится.
Ну а своей высшей фазе развития капитализм срастается корпорациями с государством, и заполненные рынки сбыта (и труда (!) требуется уже делить, увеличивая сходящую почти к нулю норму прибыли (называется всё это империализмом). Как делить - ну, например как в 1914. Рыбой, которой нельзя говорить "нет". Сначала локально выпуская эту рыбу, она постепенно захватывает весь мировой океан (ибо всё больше интересантов), а трудящиеся страдают и многие даже гибнут.
То, что Вы описали как модель, действительно будет усложняться и усложняться (причем обрастать внезапными обстоятельствами, пришедшими из материальной природы общества). Марксизм пришёл вовсе не к этому (он с этой посылки, можно сказать, начал, постулируя существование классовой борьбы), а пришёл к тому, что либо противоречие будет позитивно снято (пролетарии возьмут власть и в итоге построят бесклассовое общество, потому что они это как раз могут сделать), либо в мире будет приблизительно как у Оруэлла (и кстати да, кто-то из капиталистов даже может назвать себя "социалистами", для запутывания трудящегося... один австрийский художник именно так и поступил, к слову). Как сказала Роза Люксембург, "Социализм или варварство". А попытка "уравновесить интересы" невозможна, потому что любые "судьи" классов будут действовать в интересах настоящего правящего класса.
Daddy_Cool
15.01.2023 03:02Спасибо за развернутый комментарий!
Когда я пишу "надо платить больше" - да... я имею ввиду некую глобальную справедливость, (впрочем возможно у меня сознание деформировано советским социализмом). Можно переформулировать - "человек должен больше получать", но суть в общем та же. Строчка "Здесь мерилом работы считают усталость" - вполне имеет смысл оказывается.ednersky Автор
15.01.2023 10:00Daddy_Cool
15.01.2023 16:35Востребованность работы бизнесом? Т.е. на IT бизнесмены зарабатывают больше чем на учителях и врачах. Возможно, если срезать ЗП банковским ITшникам наполовину, удалось бы на 0.5% уменьшить процент по ипотеке выдаваемый банком ))). Еще у учителя и врача в массе невнятные критерии работы.
Пришел человек к врачу, ушел... и что? Вылечился? Забил на болезнь и страдает, ушел к другому врачу, умер? И с учителями так же. Хорошие врачи и учителя (С) (репетиторы) зарабатывают обычно хорошо, но там работает сарафанное радио - довольный результатом человек рссказывает всем о своих успехах.ednersky Автор
15.01.2023 17:29> Хорошие врачи и учителя (С) (репетиторы) зарабатывают обычно хорошо
но в среднем меньше плохих IT'шниковiig
15.01.2023 22:10Есть страны, где врачам и учителям нормально платят.
ednersky Автор
15.01.2023 22:33на уровне IT'шников учителям в среднем не платят нигде.
при том, что у учителей работа куда большей квалификации требует.
JSON'ы передвигать — много ума не нужно. Психологических сил же вообще не требуетKanut
15.01.2023 23:16на уровне IT'шников учителям в среднем не платят нигде.
А врачам?
ednersky Автор
15.01.2023 23:20Врачам — очень немногим.
Средняя по врачам оплата будет куда ниже чем средняя по айтишникам. В любой стране.
При том, что врачу нужно долго и много учиться, а айтишником может стать любой дворник, достаточно выучить пару магических слов, вроде «Монады» и кидать их направо и налево.Kanut
15.01.2023 23:27Средняя по врачам оплата будет куда ниже чем средняя по айтишникам. В любой стране.
Правда? А мне гугл почему-то говорит что средняя зарплата врача в Германии больше 80к€ в год. А средняя зарплата айтишников где-то 60-70к€ в год.
И что-то у меня есть подозрение что как минимум в Голландии, Швейцарии или там Австрии ситуация будет похожая. А скорее всего не только там.
kasthack_phoenix
16.01.2023 07:21Смотрим на реальные данные, а не левацкие фантазии:
Врачи: медиана составляет $339k в год в США.
Разработчики: медиана составляет $120k в год в США.
Размеры США(третьей страны по населению на планете после Китая и Индии), а также слово "медиана" намекают, что врачи как раз таки массово получают больше разработчиков.
im_last
15.01.2023 01:11Я сам не кодер, я по харду, эникей, но вашу статью я отлично понял.
Мне все это напомнило одного моего знакомого(из Интернета). Он, как и я, занимался мистицизмом и изучением Кастанеды.
И вот, в один из дней с ним произошло то, что я называю "взрывом осознания", эти именно то, что произошло и с вами. Он бегал по родным, друзьям, знакомым, он тормошил своих коллег по работе и всем говорил, что все плохо, что мы поражены паразитами сознания, Летунами.
В общем все закончилось тем, что он принял свое внезапное просветление за помутнение и стал проповедовать анти мистичные взгляды.
Поверьте, такие "взрывы" осознанности с людьми случаются во многих сферах.
И то что вы описали как причинно-следственную связь, на самом деле куда глубже, чем вы, возможно, сможете вообразить.
Что такое капитализм?
Капитал - это деньги.
А что такое деньги? Деньги - это эквивалент ценностей, а так как ценности неофициально признанны высшим благом в человеческой цивилизации, то тот, у кого их больше, тот имеет бОльший авторитет и бОльшую власть.
В итоге, цепочка деньги - это, - превращается в: деньги - это власть.
К чему стремятся транснациональные корпорации? К максимальному переключению всех денежных потоков на себя, а если деньги - власть над миром, тогда они негласно стремятся к этому господству.
По этому все это звенья одной цепи.
Все мы знаем состояние, когда в полудреме, мы еще толком не проснувшись, можем снова лечь на подушку и уснуть.
Современное человечество именно в таком полудреме, кто-то открыв глаза и видя пожар, вскакивает, как ужаленный и кричит, как вы - "Пожар! Пожар!" А кто-то, думает, что ему привиделось и он уверяет себя, что нужно снова уснуть, ведь когда он проснется, пожара уже не будет, потому что он на самом деле не просыпался, а видел его всего лишь в своем сне.
По этому все что в комментариях - это про тех, кто проснулся и про тех, кому просыпаться не хочется.
Но на самом деле все куда хуже, чем мы это можем вообразить, потому что все что мы видим - это то, что нам показывают... то, что нам разрешено видеть. И если это верхушка айсберга, то то, что там, под водой, вряд ли нас обрадует.
im_last
15.01.2023 01:51+3Уже сейчас бизнес нацелен на радикальное снижение уровня квалификации среднестатистического разработчика, на работника с максимально фрагментированным мышлением (чтобы не пытался, поднимаясь по социальным лифтам, составлять конкуренцию).
Ну а если мышление почему-то фрагментировано недостаточно, то и это ведь исправимо: помимо продвигаемой капиталом профессиональной фрагментации процветают и иные различные симулякры вроде всяких SJW10, BLM и т.п., мешающие человеку разобраться в ситуации, переключающие его из опасного конструктивного русла в безопасное деструктивное.
Вам нужно осознать, что это везде.
То, что мир принял как западно-европейский капитализм - это путь к тому, к чему мы пришли, но это логичный путь. Я вижу людей, которым нравятся кредиты и тот контент, который есть в Интернете, но им не нравится растлевающаяся молодежь и не нравится тот пузырь, что надувается в экономике. Так это звенья одной цепи. И в остальном вы увидите работу по тем же принципам.
Нам нравится жизнь, та жизнь, что нам дали, но нравиться она нам в частности, а вот на макромасштабе она "гниет" и начинает "вонять", но мы все равно продолжаем есть этот "кактус", как в той поговорке: мыши плакали, кололись, но продолжали есть кактус.
Луддиты были правы? Ну даже если и так, то что?!
Если бы луддиты победили, вы бы не получили столько удовольствий, а получив удовольствия за них нужно платить, просто оплата отложенна и те поколения, которые получали свое удовольствия до нашего поколения, получили свое, но должно было быть поколение в котором оплата финализируется, поколение, которе оплатит за все.
Ну вот мы в этом поколении и вот она, расплата.
Все ценности мира - 89 трлн.$ при этом всемирный долг - ~300 трлн.$
Ну так про что это? Про пирамиду, подобной МММ. Зато красиво пожили и весело.
У всего есть цена и теперь мы ее заплатим, то что автор это осознал, это только фрагмент, кусочек, на самом деле все то же самое будет почти везде и почти везде заплатят за это обычные люди, такие, как мы с вами."Wake Up, Neo" @ The Matrix
Добро пожаловать, вы вне матрицы.
botyaslonim
16.01.2023 00:23Двоякие ощущения от статьи. С одной стороны, конечно, говорить об отчуждении труда надо, это очень важный разговор. С другой, так хейтить именно микросервисы... Как было уже сказано выше, это просто логичный способ повышения эффективности труда. Это невозможно остановить. Заходить надо с другой стороны: а кто вообще программистам даёт задание писать очередной 100500-й криптокошелёк? Какая потребительная стоимость при этом создаётся? Сколько жизней от этого станет лучше? И так далее.
Ну и про линтеры. Тут автора уж совсем понесло. Единые правила написания нужны лишь для удобства чтения коллегами и самим собой позже. Автор, вас смущает, что все люди пишут комментарии следующим образом: каждое новое предложение с заглавной буквы, в конце точка, между абзацами перенос строки? Может, в школе правописание отменить, заодно и грамматику выкинуть?
pavia
Ну что, поприветствуем нового лудита. Маркер - ненависть к микросервисам. Ну и жуткая смесь социальных лозунгов и технологий. Как хоршо было раньше - телефонный диск покрутил, такси вызвал, а сейчас - кругом микросервисы и злобные капиталисты угнетают пролетариев умственного труда, отчуждая их средства производства!
auresio
Попытайтесь хотя бы немного вникнуть в прочитанный текст. Он правда шире чем штамп "говорит плохо о распространненной технологии = луддит". Потому что пока что у вас получается только клеить ярлыки. Я лично сталкивался с подобным "отуплением" разработчиков и препращением их в сугубо рабочий инструмент который хорошо умеет только 1 функцию, в то время как разрабока ПО творческий процесс который не поддается стандартизации. Когда мышление человека ограниченно какой то строго очерченой областью или даже частью области это ужасно. Вы не создадите ничего уникального имея квадратно-гнездовое мышление. И то с какой с скоростью люди добровольно заключают контракт на ограничеие собственного мышления действительно пугает. Я переписывал код за такими разработчиками и мне удавалось его ускорить до 5 раз просто потому что я решал задачу, а не ходил "проторенной тропой" которая описана в первой выдаче со стека. А что до микросервисов, там могла быть любая вещь или технология требования к которой можно хорошо формализовать и описать. Тогда испольнителей можно действителньо менять по щелчку пальца, а общая вовлеченность в процесс остается на уровне ниже плинтуса.
iig
Можно подумать, в этом есть что-то запредельно плохое. Соотношение кол-ва творцов/кол-во исполнителей (и вакансий с такими требованиями), я так подозреваю, с времён начала промышленной революции не особо меняется. Да, неквалифицированный труд не особенно высоко ценится, даже если за компом.
auresio
Плюсы в этом только у владельца бизнеса, для заменяемого это снижает его ценность на рынке труда, а соответсвенно и заработную плату. Вы к какой категории относитесь? Заменяемые или заменяющие?
Неквалифицированный труд за компом это когда охранник в магазине через комп камеры смотрит. Разработка ПО уж точно не неквалифицированный труд.
PanDubls
То же самое относится буквально к любой автоматизации производства. В конечном итоге снижение себестоимости производства снижает минимально возможную для производителя цену продажи. При достаточном уровне конкуренции реальная цена продажи стремится к этой минимальной - то есть, в выигрыше получается третья сторона - потребитель.
В конце концов, когда-то профессиональные писцы, занимавшиеся высококвалифицированной и творческой работой, знатно проиграли от распространения печатного станка.
upd: подумал, что фордовский конвейер как пример будет лучше. Также уникальные специалисты оказались в проигрыше, а общество в выигрыше.
auresio
Вы правы в своих утверждениях.
Есть только оговорка, автоматизация хороша для анонимного потребителя, для вас лично это плохо, зарабатывать вы не сможете, и будете наблюдать дешевый продукт на полках который когда то и вас кормил.
Разработчики сейчас, в том числе и мы с вами можем знатно проиграть от подобного подхода легкой замены. Плюсы будут у бизнеса. У потребителя плюсов врятли добавиться(последствия тенденции не заморачиваться, не вовлекаться и формализовать разработку) видны уже сейчас(скайп сдохни уже), для программистов это откровенный минус.
PanDubls
Ну если предлагается целенаправленно бороться с любым развитием индустрии, которое ведёт к снижению цены для конечного потребителя, но вредно для исполнителя, то можно далеко зайти. В принципе, философия тут ровно та же работает, как у сотрудника фармкомпании, который смывает в унитаз только что синтезированный препарат, излечивающий заболевание без побочных эффектов, движимого тем, что с распространением этого препарата его работа станет не нужна (пример несколько утрированный, потому что не учитывается предполагаемое снижение качества от использования микросервисов). Микроэкономически - да, выигрышная стратегия. Но этически спорная, мне кажется.
auresio
Если бросаться в крайности можно и поедание младенцев оправдать благими целями.
Но вы не забыли о чем речь изначально шла? О том что человек не видел ничего плохого в унификации и удешевлении программистов, я всего лишь обяснил краткосрочные перспективы, а не предлагал саботировать процесс и расстреливать менеджеров предлагающих ускорение/удешевление разработки.
ednersky Автор
вроде бы я старался в статье показать удорожание/замедление разработки. мало того, в моём случае это удорожание было видно в рублях
XelaVopelk
Наверное вам не поверили про замену 50 строк кода делаемых в один спринт одним человеком на несколько десятков человеколет разработки. Больше реализЪму.
auresio
В вашем случае да, но компания глобально сэкономит на найме и фонде зарплат при дальнейм развитии идеи "разботчик не важен, если что возьмем другого".
alamat42
Я так понял, в данном случае цель даже не просто в том, чтоб сэкономить. Цель в том, чтоб во-первых, никто из занятых микросервисами разработчиков не видел общей квртины того, что разрабатывается, и не мог повторить продукт, уйдя из компании. А во-вторых, низвести разработчика до уровня легкозаменимого винтика в системе, которого в любоц момент можно выбросить и заменить новым.
auddu_k
Зато появляется мотивация, найти новую нишу в которой необходим творческий потенциал.
Интересная мысль возникла: возможно такое замещение творчества автоматом как раз толкает НТП, выдавливая творцов с насиженных мест на фронтир?
auresio
Если вы молоды, горячи и любите вызовы...но некоторые из нас уже не молоды))
Я думаю такое мнение имеет право на жизнь. Наука,например, плоды которой люди попроще приватизируют и превращают в полезные вещи, мутирует постоянно. Большое количество "творцов" находясь в нестандартизированных условиях пытаются получить какой то полезный результат..
xenon
У меня есть убеждение, что программистам вообще не платят "за знание пайтона". Программистам платят за то, что он может все, даже то, чего не знает. (Берет книжку, читает, и может).
Соответственно, пока программист такой вот универсальный солдат - он очень экономически эффективен и обоснованно получает большие деньги. Как только он становится "умею крутить гайку на 14, обеспечьте меня работой" - он может зарабатывать примерно так же, как водитель убера (им тоже надо осваивать один новый абзац в ПДД раз в пять лет).
auddu_k
Прежде всего программист - тот, ктотпрофессионально работает со сложными структурами (кода, например, или данных), а язык - всего лишь средство
perfect_genius
Точно так же патентная система/авторское право являются "мутацией" в рыночном отборе — если не хочется платить автору, то придумывается свой вариант, и он может оказаться даже лучше.
0xd34df00d
Для меня лично это тоже хорошо, потому что я потребляю какие-то продукты, которые тоже подешевеют.
Areso
Подписка на Netflix пока только дорожает *пожал плечами*
0xd34df00d
Даже с коррекцией на инфляцию?
Areso
Массовое производство обуви сделало возможным то, что я могу пойти и купить пакистанские кроссовки за 10 евро на ярмарке утром воскресенья.
Хотя с поправкой на инфляцию, обувь должна стоить ну не меньше мопеда, и уж точно дороже двух порций еды в столовке.
0xd34df00d
При этом я на Черкизоне кроссовки покупал за 120 рублей 15 лет назад, что составляет этак 3-4 евро.
Areso
Тут всё зависит, откуда начать отсчет :)
Если считать от Р.Х., то цена на обувь только падала, с небольшими скачками.
У Нетфликса же цена с момента появления цена растёт.
Другой пример: цены на VPS-ки падали вплоть до 2020-го.
0xd34df00d
Ой, а что в 2020-м-то случилось?
Я уж не говорю о том, что характерные временные масштабы для обсуждаемых событий — скорее десятилетия, поэтому год-два шатаний — это так, мелочь.
vkni
Точнее 2 десятилетия, поколение. :-)
xenon
Может IP адреса подорожали? По крайней мере в scaleway подробно косты расписаны, и я вижу, что за IP-шник я плачу сравнимо с самой VPSкой.
Kanut
А при этом сам Netflix никак не меняется? Ну там не знаю, количество доступного контента например растёт?
Или ещё какие-то изменения не связанные с "автоматизацией" внутри самого Netflix?
kasyachitche
Не массовое производство, а наличие рабочей силы, готовой работать почти что за еду и перенос производства поближе к такой силе.
alamat42
В условиях лютой монополизации во многих нишах IT отрасли не всегда приходится надеяться на удешевление продуктов.
saboteur_kiev
Это от разработчиков не зависит.
Разработчикам платит бизнес, а значит бизнес устанавливает правила. Чтобы разработчики не делали, бизнес найдет способ сделать из них заменяемые винтики. Отдельные редкие случаи общую картину не испортят
DistortNeo
И в конечном итоге этот низкоквалифицированный труд вообще будет заменён нейросетевыми алгоритмами.
Jubilus
Да, зато будет конкуренция за труд более высокого уровня.
nApoBo3
Это не так. Как раз незаменимость приводит к снижению ценности специалиста на рынке труда, поскольку приводит к консервации компетенции. Да, у текущего работодателя это может приводить к более высокой чем на рынке зп, но вы становитесь заложником данного работодателя.
sshikov
Я бы сказал, что есть обе тенденции. Да, вы вникаете в конкретный бизнес, и да, за его пределами ваши компетенции (часть их, причем возможно самые дорогие) не будут нужны. Но в тоже время, человека, которые не тупой кодер, а творчески решает проблемы бизнеса, как правило оторвут с руками.
akakoychenko
А вот не все так просто. Слишком неравноценен ущерб. Незаменимый сотрудник, как правило, имеет подушку, чтобы на полгодика взять творческий отпуск, неспешно пописать пет проект на новых технологиях, попроходить тесты, литкод покрутить. А там, гляди, и готов станет собес пройти. Было бы желание, а когнитивные способности у незаменимых людей неплохи.
А работодателю безвыходка вообще без вариантов. У него есть планы, обязательства, и при уходе незаменимого удар может и бизнес завалить, если сфера динамичная.
karabas_b
Поэтому одна из самых важных задач любого бизнеса - организовать процессы так, чтобы незаменимых не было. Даже если в итоге получается дороже - это плата за стабильность.
iig
100500 раз читал, что высшее образование программисту не особо необходимо. С убедительными примерами. Ну и чем тогда программист отличается от молотобойца (помощника кузнеца)? Кузнец показывает, куда херячить - молотобоец херячит. Программисту накидывают таски в джиру - он их закрывает.
xenon
Мне кажется, в программировании очень часто время уходит на изучение (скажем, на, то как работает API телеграм или модуль телеграмма, чтобы написать бота), почти каждый проект требует что-то новое учить. Периодически надо осваивать новые языки, фреймворки.
У меня есть диплом программиста, и "по диплому" у меня прямо сертифицированные академические знания паскаля. Но насколько ценен был бы программист, если бы он искал себе работу по диплому? Мне кажется, даже водитель более востребован сейчас, чем программист на паскале -)
Программист - тот кто учится. Любой хороший фронтендер может через месяц что-то делать на бэкенде а еще через месяц писать криптовалютные контракты.
Cerberuser
А с чего вдруг "квалифицированность" == "высшее образование"?
iig
Высшее образование - это про длительное систематическое обучение. Откуда берется "квалифицированность"? Из курсов для вайтишников?
Cerberuser
Из длительного систематического обучения на практике, вероятно?
iig
Каменщик в этом смысле ничем не хуже программиста. А уж врач так на 2 головы выше.
i86com
Гроссмейстеру образование тоже неособо необходимо, но если посадить на его место молотобойца и объяснить, как фигуры двигать, то результат всё равно будет удручающим.
Так и программирование — квалифицированный труд не потому, что нужны корочки и зубрение пыльных книг, а потому что обычный «уверенный пользователь ПК» не может даже приложение в автозагрузку добавить, если в нём нет такой галочки в опциях.
iig
Обычный пользователь может иметь другую квалификацию. Он может не знать, где в Windows автозагрузка, но зато знать, в какой пропорции мешать песок, цемент и воду.
0xd34df00d
Что приводит к снижению цены и повышению доступности товаров для всех. Так что выигрывают все.
xenon
И заменяемый программист видит сигнал от Судьбы: чувак, все, на фортране ты уже много не заработаешь, учи всякие там дата-сайнс и криптовалюты - там тебя ждет много сладких работ с высокой зарплатой!
gatoazul
Ниоткуда не следует, что это приведет к снижению цены, а не к увеличению прибыли владельца.
ednersky Автор
кстати, это очень плохо!
это говорит о никчемности современного строя.
Напомню, например, одно из определений коммунизма:
warhamster
А можно спросить, что вы создали уникального на промежутке последних, ну скажем, лет десяти? Только вот прям по-честному уникального, а не имеющего уже десяток аналогов.
auresio
На Java за последний 1 год
Заточенный под нужды организации менеджер обработки собщений из кафки с несколькими очередями, приоретизацией и многопоточной обработкой.
Интеграцию с платежной системой
На Delphi за последние 4 года
Графические компоненты для отрисовки карт местности
Компоненты для работы с базами данных (аналог Hibernate из мира Java)
warhamster
Про дельфи не знаю, но неужели никто и никогда до вас не писал обработчиков для кафки и интеграций с платежными системами?
auresio
Отделяйте уникальность идеи от уникальности реализации.
Уникальных идей практически не встречается. Идея написать менеджер в общем то не уникальна, а вот уникальна реализация учитывающая особенности требований моего конкретного работодателя. Без фреймворков, ворованного кода и проч..модуль, реализующий функционал который нельзя найти в интернете хотя бы похожий. С платежными системами тоже самое. Они одни для всех организаций, идея тоже одна..но реализации не похожи и близко. Если вы пишете микросевис или прочую генерируемую на 50%-80% вещь, вам физически не хватит места что бы как то свою идею реализовать иначе чем ваш сосед по столу. В итоге откуда вам знать как можно писать код иначе если вы с самого входа в айти писали в рамках супержестких правил и генерации? Неоткуда..только если самому читать исходники людей которые писали все что придет им в голову, но откуда взяться мотивации читать чужой код если тут плаття неплохо да и куча других дел. Отсюда вывод: если у вас квадратно-гнездовое мышление или вас под него согнули вы уже с этим врятли что то сделаете, а релизовать полет фантазии вам негде да и взяться ему неоткуда.
warhamster
Я правильно понял, если человек может написать интеграцию с платежной системой, значит, у него уже не квадратно-гнездовое мышление и есть полет фантазии? Тогда ладно, я за себя спокоен.
auresio
Если оно подразумевает достаточно сложную логику, а не пару запросов и вы сами лично спроектировали и реализовали подобную интеграцию то да, без работы вы не останетесь и заменить вас одним днем будет крайне сложно.
nomorewar
Доводилось мне читать такой код. Можно нинада больше?)
auresio
Можете не читать, я разрешаю :)
А если серьезно, как и с
освежителями воздухакнигами тут надо выбирать автора, я к примеру очень много интересного увидел в коде SAS планета.nomorewar
Когда ты на работе - тут не повыбираешь автора)
0xd34df00d
Ну ок. С остальным, кажется, похожая история, судя по описанию.
auresio
Если вы опустите глаза ниже по ветке то там будет более развернуто моя точка зрения и разжевано что же именно я имел ввиду.
0xd34df00d
Что-то мне кажется, что такие уникальные и творческие задачи, как переписывание хибернейта с джавы на дельфи, не упираются в отсутствие или наличие goto или прочие атрибуты, как вы выразились, квадратно-гнездового мышления.
p07a1330
Так-то методу divide et impera не один десяток лет. В том числе в разработке ПО
0xd34df00d
И это именно потому, что микросервисы (или нет goto), а не потому, например, что область стала популярна, туда пошли люди не только за интерес, но и за деньги (и иногда только за деньги), поэтому ваши шансы повстречать не «отуплённого», а изначально «тупого» человека просто выросли?
А прочитанный текст — в основном демагогия и манипуляции.
Ну, то есть, можно озвучивать произвольные утверждения (как дальше про goto или про типизацию) — обсуждать их всё равно не обязательно, можно их просто записать в «частности».
И слегка так намекнуть на авторитетность своего мнения тоже надо пораньше к началу.
Конкретно парсеры отлично пишутся не только с goto. Таблицы, все дела. Да и на практике парсер с attoparsec будет не особо значительно отличаться от парсера с goto на сишке по скорости, но будет куда более поддерживаем и интерпретируем (и выразителен, кстати).
Зависимая инициализация и деинициализация — да хоть тот же RAII в плюсах,
bracketв хаскеле.Возможность ловить больше ошибок на этапе написания кода? Возможность легче рассуждать о коде? Да не, кому это всё нужно, это всё чушь и поветрия, лучше пойти написать ещё три goto!
В расте не то же самое. В расте вполне можно делать монадическую обработку ошибок. То, что автор ставит го и раст в один ряд — это очень показательно (и довольно иронично, учитывая общий лейтмотив претензий к современному поколению, не видящему всю картину в целом). Давайте ещё, блин, идрис в этот ряд добавим — там исключений тоже нет, тоже как в го сделано, наверное.
Удивлён отсутствием наиболее очевидного предположения, что этот миллиард распиливался как надо. Согласился бы автор пилить микросервисы — нашлись бы другие причины, почему нельзя.
Про марксистские лозунги даже говорить не хочу, там, как всегда в марксизме, логика выключается, и подчёркивать каждый некорректный логический переход себе дороже. Одно только интересно — когда я бью код на модули, чтобы каждый из них был более взаимозаменяем и изолирован, когда всякие там ООП-чуваки пытаются в паттерны, чтобы сделать код более абстрактным и его компоненты более взаимозаменяемыми, мы тоже там что-то отчуждаем? Когда я в личном хобби-проекте наворачиваю абстракций, чтобы кусок кода (и себя в процессе его разработки) изолировать от целого, когда я выношу вещи в отдельные библиотеки — я что-то отчуждаю? От кого и к кому?
За фразу про симулякры, впрочем, лойс. Всегда отрадно встретить человека, который понимает одну из причин существования этих явлений, пусть и далеко не основную.
ednersky Автор
ну дык написанный вами - ещё большая демагогия.
по сути вы ничего не сказали.
микросервисы - организационная а не технологическая штука - это не опровергнуто
парсеры пишутся не только с goto - удивительно что это было бы не так. статья это не постулирует
и в общем всё как всегда в спорах с вашим ником - извините, но вы мне перестали быть интересны ещё в прошлых моих инкарнациях на habr
0xd34df00d
Ложная дихотомия. Штука одновременно может быть и организационной, и технологической (потому что технологии и организация накладывают друг на друга ограничения), и я, если честно, не вижу особых поводов об этом дискутировать, потому что конкретная доля в этом разделении ни на что не влияет. Главное — что у микросервисов есть некоторые технологические преимущества (возможность писать на разных языках, возможность изолировать потенциально падучие компоненты, возможность скейлиться, и так далее), поэтому иногда они оправданы. Конечно, как и всегда, нужно знать меру, и пихать микросервисы везде не обязательно.
Ваши слова:
так что статья кое-что постулирует, но либо здесь, либо чуть раньше вы подменяете тезис.
Не укажут мне теперь путь, увы и ах.
ednersky Автор
не укажут, демагогией заниматься неинтересно. Ваш ник - признак того, что она началась.
0xd34df00d
Вы придираетесь к частностям вместо того, чтобы обсуждать по сути.
ednersky Автор
(ещё раз) заглянул в ваш профиль
у нас с вами большая разница: вы работаете на трендах, я работаю против них
поэтому вы смотрите на меня свысока: дескать что за быдло тут
ну а я смотрю на вас как на ничтожество.
ничего личного, просто констатация фактов
0xd34df00d
На каких трендах? Я не умею в веб и эти ваши жс-тс-бабелы-екмаскрипт-2030, не умею в го, не особо умею в раст, пол-жизни прописал на плюсах (там, кстати, есть гото и экзепшоны), остаток — на хаскеле (которому за 30 лет уже). Что тут трендового?
Да и вообще, вот прямо сейчас передо мной открыта книжка 80-х годов, я по ней что-то новое изучаю.
Как на быдло я смотрю только на тех, кто не умеет в аргументацию своего мнения, но претендует на умение, пафос и жизненный опыт.
ednersky Автор
> На каких трендах?
типы, разделение труда, как легализоваться в омерике итп
0xd34df00d
Типы в тренд вошли сильно после того, как я ими заинтересовался.
Это у меня в профиле? Вряд ли — на самом деле я просто очень скучный и разделяю труд, который мне интересен, и который неинтересен.
Я там вообще по течению плыл, даже работать не нужно было. Да и «легализоваться» подразумевает изначально нелегальный статус, а это ну такое.
ednersky Автор
вот опять вы не в силах разобраться с прочитанным
разве я хоть в одном месте написал о том, когда появились/вошли в тренд типы?
0xd34df00d
«Работаете на трендах» подразумевает, что что-то сначала становится трендовым, а потом этот работающий этим начинает заниматься. Если очень везёт, то лаг неизмеримо мал.
Давайте вы в слова с кем-нибудь другим играть будете.
ednersky Автор
ухты! одно из моих предложений дошло до вашего мозга! круто! прогресс!
0xd34df00d
Окей, возвращаемся назад:
Совместить это с предыдущим смогёте, чтобы сделать вывод, что «работаете на трендах» в данном случае некорректно?
ednersky Автор
типы вошли в тренд после
вы писали в тренде ещё после
https://www.youtube.com/watch?v=g93r-UQZtn8
0xd34df00d
То есть, достаточно один раз в жизни что-то делать, пока оно в тренде, чтобы теперь говорилось «вы работаете на трендах»? Круто.
Я уж не говорю о том, что проводить какие-то серьёзные параллели между условным typescript/mypy и вот этой вот всей ненужной ерундой, которой я занимаюсь — ну, как-то очень натянуто.
ednersky Автор
почему один? (глядя в ваш профиль) вы делаете это постоянно
0xd34df00d
Мне интересны граничные условия.
И нет, увы, хаскель, агда и прочее ненужно всё ещё не в тренде, как бы мне того ни хотелось.
ednersky Автор
мне — неинтересны
граничные условия — всегда уникальны, по ним нельзя строить обобщения
0xd34df00d
Зато по ним можно проверять обобщения.
Впрочем, я тут как пессимист на вещи смотрю. Лучше быть оптимистом! Например, можно я на вас буду ссылаться, когда мне в следующий раз будут говорить, что хаскель — ненужный маргинальный язык? А я так человеку хоп и ссылку на ваш комментарий, где написано, что я работаю в тренде (а так как наиболее мейнстримная из вещей, с которыми я работаю — хаскель, то, следовательно, хаскель в тренде).
ednersky Автор
наоборот. обобщения как правило делаются по среднестатистическому, по тренду итп. и в граничных условиях перестают работать.
потому проверять их тут, будете ну разве что вы
0xd34df00d
Ну ок, какое у меня пересечение с трендами? Какой у меня тренд трендов?
ednersky Автор
например описанный в статье — тренд на типизацию
тренд == поветрие
0xd34df00d
Вы способны читать, что вам пишут, или тут тоже без goto не обойтись?
Какое конкретно у меня пересечение с трендом? Ну вот сколько времени из того, что я занимаюсь хаскелем, хаскель является трендовой вещью?
ednersky Автор
короче, нах иди, надоел
0xd34df00d
Фигня вопрос, не могу перечить советам бывалых.
Только это, подскажите всё же, ссылаться на вас для доказывания трендовости хаскеля можно? По каким регалиям? Ну там, магистр наблюдений за индустрией, доктор goto, кандидат динамико-типических наук, не знаю.
ednersky Автор
чтобы ссылаться на меня, ты сперва должен научиться читать, что я пишу. но, увы, у тебя пока с этим проблема
0xd34df00d
Ваш тезис: я работаю на трендах.
Наблюдаемый факт: мой основной язык последнее время — хаскель.
Вывод: хаскель — тренд.
Опять вас не так поняли?
ednersky Автор
ага и он (тезис) по списку статей в профиле.
шушара побежала от мобилизации — ты словил тренд и тиснул статейку про гринкарты.
это именно тренд. хацкель тут не при чём.
0xd34df00d
Тогда в чём проблема с чтением?
Приятно быть гигантом, которого не останавливают такие мелочи, как принцип причинности!
ednersky Автор
ну шушара бежала и до мобилизации, на то она и шушара.
ты ж — её представитель, типичный
0xd34df00d
Шушара (что бы это ни значило) побежала от мобилизации до мобилизации и даже до появления поводов для мобилизации? Шушара — это походу что-то умное, может, ей быть не так уж и плохо?
kha0s
После этого оскорбления собеседника я о вас, в принципе всё понял. Держу пари, ваш разговор с начальником в статье был «немного» другим.
— Давайте вкорячим грязный хак в три продовых системы? Нет? А как же ТВОРЧЕСТВО.
А кто отвечать и поддерживать потом будет все это творчество вы так и не сказали. Карл Маркс? То-то и оно.
ednersky Автор
неужели на себя вы смотрите как на быдло?
ни в жизть не поверю (опять просмотрел ваш профиль)
0xd34df00d
Столько опыта, столько наблюдений над состоянием разработки, такой обширный культурный багаж (Руссо, Ленин, Бодрийяр), и всё, что вы осиливаете произвести — вариации на тему «нет ты»?
ednersky Автор
вы же иного варианта не приемлете, этот — хотя бы понимаете
0xd34df00d
Других вариантов от вас что-то пока не особо наблюдалось. Ну, если не считать поток слов на тему монады коллбеки файберы копродукт… тьфу, корутины. Где там в монадических парсерах коллбеки, непонятно до сих пор.
Хотя, возможно, вы имели в виду, что монады заменяют коллбечный ад, но тогда всё ещё хуже.
ednersky Автор
ещё раз: монады — способ преобразовать лапшу из ада последовательных колбеков в нечто похожее на императив
чем монады отличаются от промисов? ТОЛЬКО ОДНИМ: промисы реализуют строго один (наиболее частый) паттерн, а монады — ажно четыре.
вот собственно и всё.
попробуйте осмыслить это
0xd34df00d
Что императивного в примере с парсерами?
Что императивного здесь?
Четыре чего, паттерна? Это какие? Объясните ничтожеству плз.
ednersky Автор
четыре ажно варианта: до первой ошибки, все варианты вообще, ну и так далее.
я понимаю, что трудно осилить, но попробуйте: чем монада от промиса отличается?
0xd34df00d
Ой, что ж тут делается-то, а?
А также логгирование (
Writer), общий environment без возможности модификации (Reader), иммутабельное «состояние» (State), мутабельное состояние (ST), транзакционный параллелизм (STM)… ой, уже точно больше четырёх получается, а ведь ещё естьParserиз моего примера, промисы из вашего примера…Промис — частный случай монады, не наоборот. Ну и ещё почти везде промисы сделаны чутка кривовато и не имеют монадического API, но подробное обсуждение этой темы уведёт нас сильно в сторону.
gatoazul
Разверните, пожалуйста, тему. Чем промисы сделаны неправильно и какого АПИ в них не хватает? Не ради дискуссии, реально интересно.
0xd34df00d
Например, у
std::futureв тех же плюсах сильно не хватаетthen, которая бы принимала функцию, принимающую голый результат и возвращающую новыйfuture.Плюс, во всех известных мне языках смешивается семантика «выполнится потом» и «может привести к ошибке», тогда как это две разные вещи и два разных эффекта, которые полезно разделять хотя бы ментально. Поэтому у промисов/фючеров появляются всякие там
onError, и прочая подобная ерунда.AnthonyMikh
В Rust разделены, там футура может возвращать
Result, аналог хаскельногоEither.ednersky Автор
варианты колбеков, вид сбоку
перестаньте совать всюду свой ацтойный язык, попробуйте например на JS написать аналог Монад.
кроме как с лямбдами у вас это не получится никак.
0xd34df00d
Где конкретно здесь коллбеки?
Где императивщина в примере с парсером? Я не отстану, сказали А — скажите Б.
Канеш ацтойный, слишком просто всё получается, не получается сказать «да это всё нинужно, 25 лет назад я писал то же самое проще».
Я правильно понимаю, что если на каком-то языке $концепция не выражается нормальным образом, а выражается только через $костыль, то $концепция — это $костыль, вид сбоку?
ednersky Автор
неправильно.
ещё раз: берём питон с колбеками и промисами. потом питон делает шаг и добавляет операторы async/await и прячет колбеки под капотом.
вопрос: колбеки перестали существовать?
ответ: они никуда не делись, просто об однообразном оформлении теперь заботится интерпретатор
вопрос: после того как сделан такой шаг, нужны ли программисту монады?
ответ: нет, нафиг не нужны
0xd34df00d
Я правильно понимаю, что вы считаете, что «промисы — частный случай монад, но монады не являются частным случаем промисов» — то же самое, что «промисы и монады одно и то же»?
ednersky Автор
как всегда неправильно
0xd34df00d
Как иначе интерпретировать
?
ednersky Автор
всё что можно сделать монадами можно делать и промисами. просто сложнее.
когда синтаксис промисов запихали под капот, эта сложность размывается и ни монады ни промисы не нужны
0xd34df00d
Это действительно патологический идиотизм.
автоматически означает, что монады — подмножество промисов, просто с точки зрения их денотаций.
Вы бы там определились со своими утверждениями.
ednersky Автор
нет
если математическая библиотека поставляет четыре оператора умножить разделить сложить и вычесть
а другая — поставляет ещё и синус, то ни первая ни вторая не является подмножеством.
синус можно вычислить и с использованием первой и с использованием второй. просто во второй за вас это кто-то сделал запихав в соответствующую функцию.
новой парадигмы вторая библиотека не несёт. — это центральный тезис
0xd34df00d
Это означает, что множество операций, реализуемых с помощью первой библиотеки, является подмножеством операций со второй (и обратно, кстати).
Разговаривать с людьми, которые противоречат сами себе в каждом комментарии и при этом всё равно прут напролом, совершенно этого не стесняясь, я не умею и не вижу необходимости учиться, впрочем.
ednersky Автор
ну вот, наконец-то! именно так. промис покрывает 95% необходимостей возни с колбеками. кому-то захотелось покрыть оставшиеся 5 — наваяли фигню, назвали монадами.
в языке где есть файберы или корутины ни монады ни промисы становятся нафиг не нужны
0xd34df00d
Что «наконец-то»? Не делайте вид, будто вы не обделались, изначально подразумевая, что кроме промисов монад не бывает.
Это уже какая-то патология. Вы опять строите свою наркоманскую логическую цепочку «промисы — подмножество монад, промисы заменяются на коллбеки, значит монады — нужны для возни с коллбеками».
Я не верю, что человек, который может взять компьютер или хотя бы смартфон и им пользоваться, а также найти там кнопку «отправить комментарий», может допускать такие ошибки в логике.
А парсер вы будете писать на файберах или на корутинах?
ednersky Автор
а парсер я буду писать с применением стейтмашины. в этом месте использование монад — тупое переусложнение.
равно как и повсеместное использование типов
0xd34df00d
Ну да, код на комбинаторах вроде примера выше — слишком сложно, писать стейтмашину руками куда проще.
ednersky Автор
ну да
0xd34df00d
Можно, ну чисто ради интереса и обучения у великих, пример парсера на описанных руками стейтмашинах за вашим авторством?
ednersky Автор
можно
0xd34df00d
У вас ссылка отклеилась.
ednersky Автор
Салтыков-Щедрин:
sshikov
Отупление разработчиков не приводит ни к чему хорошему. Да, вы можете их уволить и заменить — но работать они будут хуже тех, которые не тупые. Поэтому те кто так поступает, в какой-то степени роют себе яму. Даже если не подозревают об этом.
>общая вовлеченность в процесс остается на уровне ниже плинтуса
В том числе и поэтому. Если процесс совершенствуют только избранные, а не все, если вовлеченность на нуле — ни к чему хорошему это не приведет.
ultraElephant
А какое отношение способ деплоймента и комуникации (микросервисы) имеет к процессу разработки, и уж тем более как ограничивает его. Можно просто с такой же уверенностью сказать, что мэйкфайлы (или пакетирование) ограничивают.
XelaVopelk
Да-да-да. Марксизм в натуральном виде.
https://www.marxists.org/russkij/marx/1867/capital_vol1/29.htm
"...Машинный труд, до крайности захватывая нервную систему, подавляет многостороннюю игру мускулов и отнимает у человека всякую возможность свободной физической и духовной деятельности[707]. Даже облегчение труда становится средством пытки, потому что машина освобождает не рабочего от труда, а его труд от всякого содержания. Всякому капиталистическому производству, поскольку оно есть не только процесс труда, но в то же время и процесс возрастания капитала, присуще то обстоятельство, что не рабочий применяет условно труда, а наоборот, условие труда применяет рабочего, но только с развитием машины это извращённое отношение получает технически осязаемую реальность. Вследствие своего превращения в автомат средство труда во время самого процесса труда противостоит рабочему как капитал, как мёртвый труд, который подчиняет себе живую рабочую силу и высасывает её. Отделение интеллектуальных сил процесса производства от физического труда и превращение их во власть капитала над трудом получает своё завершение, как уже указывалось раньше, в крупной промышленности, построенной на базе машин. Частичное искусство отдельного машинного рабочего, подвергшегося опустошению, исчезает как ничтожная и не имеющая никакого значения деталь перед наукой, перед колоссальными силами природы и перед общественным массовым трудом, воплощёнными в системе машин и создающими вместе с последней власть «хозяина» (master). ..."
ksbes
Смех смехом. Но когда своими руками автоматизируешь цех и в реальном времени видишь как истинные мастера своего дела способные на токарном станке розу выточить (буквально) замещаются простыми переносителями болванок/нажимателями кнопок — начинаешь в такое верить.
Есть надежды на «тёмный цех» — что совсем устранит необходимость в однообразном труде. Но глядя на всё растущую коприрастию появляются опасения, что это будет просто переход на следующий круг…
Eugeeny
Мастерам - место в новых разработках и работе над прототипами.
Areek
Токарщик с разрядом по вытачиванию роз этим не занимается в принципе. Это вопрос к НИИ, к инженерам.
Daddy_Cool
Это проблема, розы выточенные на станке не нужны.
У нас есть механик в лаборатории (токарь-фрезеровщик-всё-в одном лице), так после того как мы купили ЧПУ - мы его напрягаем значительно реже.
А что такое "темный цех"?
Toxygen
>А что такое "темный цех"?
Думаю по аналогии с dark stores - цех без работников.
svosin
https://en.wikipedia.org/wiki/Lights_out_(manufacturing)
gatoazul
Вы напрасно считаете пассаж смешным. Маркса волнует состояние человека, а не прогресс цивилизации. Труд действительно постоянно деградирует, становится все более не-человеческим.
Рекомендую для подробного изучения работу Гарри Бравермана "Труд и монополистический капитал: деградация труда в XX веке"
karabas_b
Прогресс цивилизации и влияет на состояние человека, причем влияет позитивно. Со времен Маркса люди стали работать существенно меньше, а благ потреблять намного больше. "Труд деградирует и становится нечеловеческим" это просто демагогия. Труд это работа, которую совершают люди для блага других людей. Он человеческий по определению.
ednersky Автор
так скажем — далеко не все
alamat42
Шутка в том, что не последнюю роль в этом сыграла именно борьба рабочих за свои права. И марксизм в том числе, как теоритическая основа для всякого рода социалистов и социал-демократов.
Имеется в виду, что рабочий, который по 12 часов в день совершает на конвецере однообразные действия (например, перекладывает деталь от одного станка к другому), занимается тяжелым отупляющим трудом, становясь живым винтиком в конвейере.
Такой труд не оставляет места для творчества, скорей всего вреден здоровью, и угнетающе дейтвует на живого человека.
По крайней мере так оно было во времена Маркса. И скорей всего, встречается и сейчас, особенно там, где дешевая рабочая сила.
randomsimplenumber
Тяжёлый отупляющий труд придуман очень сильно задолго до капитализма. Механизация делает тяжёлый труд легче - до капитализма это было не востребовано. А что не везде есть место творчеству.. Так и люди разные. Можно креативно убирать снег с дороги, можно лечить людей строго по протоколу.
gatoazul
Если вы не поняли идею, переформулирую: сам труд все больше не соответствует психике и физиологии человека, например, требует от него постоянной концентрации внимания и быстрой реакции, заставляет делать однообразные движения, не дает чувства сопричастности и смысла.
WraithOW
Вы картоху хоть раз в жизни копали?
gatoazul
Вы хотите познакомиться с моей биографией и жизненными впечатлениями, или ваш вопрос каким-то образом относится к ведущейся дискуссии?
DaneSoul
gatoazul
Раньше - это во время промышленной цивилизации, но без экскаватора, или все-таки раньше, когда человек строил себе дом сам? В последнем случае, это реально было творчество и креатив, даже с лопатой в руках.
Боюсь, что вы вообще не понимаете, о чем речь.
DaneSoul
gatoazul
А вы точно поняли, что речь в моем комментарии идет не о проблемах потребителя, а о проблемах непосредственного производителя?
...И в конце этого пути мы получаем "Первых людей на Луне" Уэллса. Ну или "Геном" Лукьяненко, если хотите.
DaneSoul
gatoazul
Себе он нужен. Вы же не пытаетесь оправдать рабство, я надеюсь?
DaneSoul
Нет, я не оправдываю рабство, и вообще считаю это странным аргументом, как доведение идеи до абсурда.
Но я не только работник, но и потребитель услуг и товаров произведенных другими людьми. И как потребитель я заинтересован получать качественную услугу по доступной цене, а не хоть что-то за бешеные деньги, потому как производитель вот такой супер одухотворенный и ему только творчество интересно, а не мои проблемы.
WraithOW
Да, и раньше. Вот тебе поле, вот мотыга, херач отсюда и до заката. Такой креатив, что обделаться надо.
Сразу видно городских теоретиков. Вы б на своих 6 сотках хотя б годик повпахивали с лопатой - сразу б по-другому запели.