Comments 1018
Ну что, поприветствуем нового лудита. Маркер - ненависть к микросервисам. Ну и жуткая смесь социальных лозунгов и технологий. Как хоршо было раньше - телефонный диск покрутил, такси вызвал, а сейчас - кругом микросервисы и злобные капиталисты угнетают пролетариев умственного труда, отчуждая их средства производства!
Попытайтесь хотя бы немного вникнуть в прочитанный текст. Он правда шире чем штамп "говорит плохо о распространненной технологии = луддит". Потому что пока что у вас получается только клеить ярлыки. Я лично сталкивался с подобным "отуплением" разработчиков и препращением их в сугубо рабочий инструмент который хорошо умеет только 1 функцию, в то время как разрабока ПО творческий процесс который не поддается стандартизации. Когда мышление человека ограниченно какой то строго очерченой областью или даже частью области это ужасно. Вы не создадите ничего уникального имея квадратно-гнездовое мышление. И то с какой с скоростью люди добровольно заключают контракт на ограничеие собственного мышления действительно пугает. Я переписывал код за такими разработчиками и мне удавалось его ускорить до 5 раз просто потому что я решал задачу, а не ходил "проторенной тропой" которая описана в первой выдаче со стека. А что до микросервисов, там могла быть любая вещь или технология требования к которой можно хорошо формализовать и описать. Тогда испольнителей можно действителньо менять по щелчку пальца, а общая вовлеченность в процесс остается на уровне ниже плинтуса.
испольнителей можно действителньо менять по щелчку пальца
Можно подумать, в этом есть что-то запредельно плохое. Соотношение кол-ва творцов/кол-во исполнителей (и вакансий с такими требованиями), я так подозреваю, с времён начала промышленной революции не особо меняется. Да, неквалифицированный труд не особенно высоко ценится, даже если за компом.
Можно подумать, в этом есть что-то запредельно плохое.
Плюсы в этом только у владельца бизнеса, для заменяемого это снижает его ценность на рынке труда, а соответсвенно и заработную плату. Вы к какой категории относитесь? Заменяемые или заменяющие?
Да, неквалифицированный труд не особенно высоко ценится, даже если за компом.
Неквалифицированный труд за компом это когда охранник в магазине через комп камеры смотрит. Разработка ПО уж точно не неквалифицированный труд.
Плюсы в этом только у владельца бизнеса, для заменяемого это снижает его ценность на рынке труда, а соответсвенно и заработную плату.
То же самое относится буквально к любой автоматизации производства. В конечном итоге снижение себестоимости производства снижает минимально возможную для производителя цену продажи. При достаточном уровне конкуренции реальная цена продажи стремится к этой минимальной - то есть, в выигрыше получается третья сторона - потребитель.
В конце концов, когда-то профессиональные писцы, занимавшиеся высококвалифицированной и творческой работой, знатно проиграли от распространения печатного станка.
upd: подумал, что фордовский конвейер как пример будет лучше. Также уникальные специалисты оказались в проигрыше, а общество в выигрыше.
Вы правы в своих утверждениях.
Есть только оговорка, автоматизация хороша для анонимного потребителя, для вас лично это плохо, зарабатывать вы не сможете, и будете наблюдать дешевый продукт на полках который когда то и вас кормил.
Разработчики сейчас, в том числе и мы с вами можем знатно проиграть от подобного подхода легкой замены. Плюсы будут у бизнеса. У потребителя плюсов врятли добавиться(последствия тенденции не заморачиваться, не вовлекаться и формализовать разработку) видны уже сейчас(скайп сдохни уже), для программистов это откровенный минус.
Ну если предлагается целенаправленно бороться с любым развитием индустрии, которое ведёт к снижению цены для конечного потребителя, но вредно для исполнителя, то можно далеко зайти. В принципе, философия тут ровно та же работает, как у сотрудника фармкомпании, который смывает в унитаз только что синтезированный препарат, излечивающий заболевание без побочных эффектов, движимого тем, что с распространением этого препарата его работа станет не нужна (пример несколько утрированный, потому что не учитывается предполагаемое снижение качества от использования микросервисов). Микроэкономически - да, выигрышная стратегия. Но этически спорная, мне кажется.
Ну если предлагается целенаправленно бороться с любым развитием индустрии, которое ведёт к снижению цены для конечного потребителя, но вредно для исполнителя, то можно далеко зайти.
Если бросаться в крайности можно и поедание младенцев оправдать благими целями.
Но вы не забыли о чем речь изначально шла? О том что человек не видел ничего плохого в унификации и удешевлении программистов, я всего лишь обяснил краткосрочные перспективы, а не предлагал саботировать процесс и расстреливать менеджеров предлагающих ускорение/удешевление разработки.
а не предлагал саботировать процесс и расстреливать менеджеров предлагающих ускорение/удешевление разработки.
вроде бы я старался в статье показать удорожание/замедление разработки. мало того, в моём случае это удорожание было видно в рублях
Наверное вам не поверили про замену 50 строк кода делаемых в один спринт одним человеком на несколько десятков человеколет разработки. Больше реализЪму.
В вашем случае да, но компания глобально сэкономит на найме и фонде зарплат при дальнейм развитии идеи "разботчик не важен, если что возьмем другого".
Я так понял, в данном случае цель даже не просто в том, чтоб сэкономить. Цель в том, чтоб во-первых, никто из занятых микросервисами разработчиков не видел общей квртины того, что разрабатывается, и не мог повторить продукт, уйдя из компании. А во-вторых, низвести разработчика до уровня легкозаменимого винтика в системе, которого в любоц момент можно выбросить и заменить новым.
Есть только оговорка, автоматизация хороша для анонимного потребителя, для вас лично это плохо, зарабатывать вы не сможете, и будете наблюдать дешевый продукт на полках который когда то и вас кормил.
Зато появляется мотивация, найти новую нишу в которой необходим творческий потенциал.
Интересная мысль возникла: возможно такое замещение творчества автоматом как раз толкает НТП, выдавливая творцов с насиженных мест на фронтир?
Зато появляется мотивация, найти новую нишу в которой необходим творческий потенциал.
Если вы молоды, горячи и любите вызовы...но некоторые из нас уже не молоды))
Интересная мысль возникла: возможно такое замещение творчества автоматом как раз толкает НТП, выдавливая творцов с насиженных мест на фронтир?
Я думаю такое мнение имеет право на жизнь. Наука,например, плоды которой люди попроще приватизируют и превращают в полезные вещи, мутирует постоянно. Большое количество "творцов" находясь в нестандартизированных условиях пытаются получить какой то полезный результат..
У меня есть убеждение, что программистам вообще не платят "за знание пайтона". Программистам платят за то, что он может все, даже то, чего не знает. (Берет книжку, читает, и может).
Соответственно, пока программист такой вот универсальный солдат - он очень экономически эффективен и обоснованно получает большие деньги. Как только он становится "умею крутить гайку на 14, обеспечьте меня работой" - он может зарабатывать примерно так же, как водитель убера (им тоже надо осваивать один новый абзац в ПДД раз в пять лет).
Точно так же патентная система/авторское право являются "мутацией" в рыночном отборе — если не хочется платить автору, то придумывается свой вариант, и он может оказаться даже лучше.
Подписка на Netflix пока только дорожает *пожал плечами*
Массовое производство обуви сделало возможным то, что я могу пойти и купить пакистанские кроссовки за 10 евро на ярмарке утром воскресенья.
Хотя с поправкой на инфляцию, обувь должна стоить ну не меньше мопеда, и уж точно дороже двух порций еды в столовке.
Тут всё зависит, откуда начать отсчет :)
Если считать от Р.Х., то цена на обувь только падала, с небольшими скачками.
У Нетфликса же цена с момента появления цена растёт.
Другой пример: цены на VPS-ки падали вплоть до 2020-го.
Не массовое производство, а наличие рабочей силы, готовой работать почти что за еду и перенос производства поближе к такой силе.
В условиях лютой монополизации во многих нишах IT отрасли не всегда приходится надеяться на удешевление продуктов.
Разработчики сейчас, в том числе и мы с вами можем знатно проиграть от подобного подхода легкой замены. Плюсы будут у бизнеса. У потребителя плюсов врятли добавиться(последствия тенденции не заморачиваться, не вовлекаться и формализовать разработку) видны уже сейчас(скайп сдохни уже), для программистов это откровенный минус.
Это от разработчиков не зависит.
Разработчикам платит бизнес, а значит бизнес устанавливает правила. Чтобы разработчики не делали, бизнес найдет способ сделать из них заменяемые винтики. Отдельные редкие случаи общую картину не испортят
И в конечном итоге этот низкоквалифицированный труд вообще будет заменён нейросетевыми алгоритмами.
Плюсы в этом только у владельца бизнеса, для заменяемого это снижает его ценность на рынке труда,
Это не так. Как раз незаменимость приводит к снижению ценности специалиста на рынке труда, поскольку приводит к консервации компетенции. Да, у текущего работодателя это может приводить к более высокой чем на рынке зп, но вы становитесь заложником данного работодателя.
А вот не все так просто. Слишком неравноценен ущерб. Незаменимый сотрудник, как правило, имеет подушку, чтобы на полгодика взять творческий отпуск, неспешно пописать пет проект на новых технологиях, попроходить тесты, литкод покрутить. А там, гляди, и готов станет собес пройти. Было бы желание, а когнитивные способности у незаменимых людей неплохи.
А работодателю безвыходка вообще без вариантов. У него есть планы, обязательства, и при уходе незаменимого удар может и бизнес завалить, если сфера динамичная.
Разработка ПО уж точно не неквалифицированный труд.
100500 раз читал, что высшее образование программисту не особо необходимо. С убедительными примерами. Ну и чем тогда программист отличается от молотобойца (помощника кузнеца)? Кузнец показывает, куда херячить - молотобоец херячит. Программисту накидывают таски в джиру - он их закрывает.
Мне кажется, в программировании очень часто время уходит на изучение (скажем, на, то как работает API телеграм или модуль телеграмма, чтобы написать бота), почти каждый проект требует что-то новое учить. Периодически надо осваивать новые языки, фреймворки.
У меня есть диплом программиста, и "по диплому" у меня прямо сертифицированные академические знания паскаля. Но насколько ценен был бы программист, если бы он искал себе работу по диплому? Мне кажется, даже водитель более востребован сейчас, чем программист на паскале -)
Программист - тот кто учится. Любой хороший фронтендер может через месяц что-то делать на бэкенде а еще через месяц писать криптовалютные контракты.
высшее образование программисту не особо необходимо. С убедительными примерами.
А с чего вдруг "квалифицированность" == "высшее образование"?
Так и программирование — квалифицированный труд не потому, что нужны корочки и зубрение пыльных книг, а потому что обычный «уверенный пользователь ПК» не может даже приложение в автозагрузку добавить, если в нём нет такой галочки в опциях.
И заменяемый программист видит сигнал от Судьбы: чувак, все, на фортране ты уже много не заработаешь, учи всякие там дата-сайнс и криптовалюты - там тебя ждет много сладких работ с высокой зарплатой!
Ниоткуда не следует, что это приведет к снижению цены, а не к увеличению прибыли владельца.
Потерявшему работу не очень радостно от снижения цены на N процентов, когда зарплата равна нулю.
Соотношение кол-ва творцов/кол-во исполнителей (и вакансий с такими требованиями), я так подозреваю, с времён начала промышленной революции не особо меняется.
кстати, это очень плохо!
это говорит о никчемности современного строя.
Напомню, например, одно из определений коммунизма:
Коммунизм — раскрепощение и пробуждение высших творческих способностей в каждом человеке.
Коммунизм — раскрепощение и пробуждение высших творческих способностей в каждом человеке
Я чувствую в себе великий творческий потенциал строить на пляже очень креативные замки из песка, в перерывах попивая что-то прохладное. Но мне дают лопату и говорят - "вот лопата, вот песок, вот бетономешалка. твори давай."
Творчество это прекрасно (см скульптуры_из_песка.жпг), но для этого нужно долго и упорно учиться. Кидать песок лопатой проще.
проблема людей с фрагментарным мышлением (в статье об этом есть) как раз в том и состоит, что они видят/сосредотачиваются исключительно на фрагменте, но целое не могут осилить.
В данном случае Вы, прочитав определение цели, фрагментарно стали смотреть только на неё и не можете понять: пока что она не достигнута. Чтобы этот фреймворк заработал, нужно ещё написать 100500 микросервисов.
В общем неудивительно, что вас заставляют кидать песок, вы ведь при капитализме живёте.
А при коммунизме его кто будет кидать?
мы вообще никогда не понимали: зачем закапывать пять вёдер картохи, чтобы по осени выкопать десять (или сколько там), и всегда рассматривали этот унылый ручной труд, как недоступное нашему пониманию развлечение.
То, что это именно развлечение я однажды понял на своей шкуре: приехали на майские к другу на шашлыки, а у него дом, участок, все дела. Ну и пока до назначенного мероприятия оставалось несколько часов, я, от нечего делать, взял лопату в руки и вскопал там… не помню. Кажется две сотки.
Устал прилично, но вечером, понял, что это хорошо/полезно/приятно для организма. В общем вспоминал вполне с удовольствием и когда снова попадал туда — опять где-то в чём-то помогал.
Вот бежать на беговой дорожке — не моё. Это какие-то бессмысленные телодвижения. А копать — вполне норм.
Правда дачу себе я заводить не стал и не стану, хотя возможность есть.
В общем, что я хотел сказать? Копать будет тот, кому хочется и нравится копать. Если вам (и мне) это не нравится, то вы (и я) — нерепрезентативная выборка.
Тех кому нравится копать и бетон мешать много. Очень много.
А почему вы так уверены в том, что потребность в тех, кто копает и мешает бетон, будет полностью закрыта теми, кому этот вид деятельности нравится?
"На сегодня потребности в колбасе нет", так и запишем.
количество предпринимателей — 1%
количество предпринимателей, дающих работу 95% работников — ещё в десять раз меньше
Итого: большинству совершенно пофиг где работать: госкомпании или частной, важно, чтобы условия были приемлемыми. Вопросы смены строя затрагивают интересы унылого одного процента (ограничение сверху) людей, в большинстве своём неправедно владеющими капиталом.
Вот далеко ходить не будем.
Возьмём например Микрософт. Мальчик Билли, заработал на этом сотню-другую ярдов $$, то есть человечество за это поделие (шиндовс) заплатило сотню-другую ярдов.
а какова себестоимость?
а себестоимость оценивается довольно просто: берём аналог Шиндовс, ну скажем ReactOS. Функционал? Такой же. Какие-то программы не запускаются, но не потому что система технологически отстаёт, а потому что часть информации об интерфейсах закрыта/недоступна. Считая что ReactOS содержит в себе 95% функциональности Шиндовс, можно сделать вывод, что себестоимость двух систем соизмерима (разница в пределах двух-трёх раз, не более).
Далее смотрим список разработчиков и видим, что ограничивая сверху, они потратили на это ну не более сотни человеколет.
А человечество за продукт себестоимостью в сотню человеколет потратило сотни миллиардов долларов.
А ещё сотни миллиардов долларов на айфоны.
а если бы строй был более справедливым, то эти деньги могли быть потрачены на создание ТЯЭС, базы на Луне и Марсе итп
но «на сегодня потребности в колбасе нет». ТЯЭС никому не нужна, капиталу для самосохранения требуется переформатирование мира к новому фашистскому строю (логичное продолжение капитализма).
Для этого устроены войны, для этого придуман ковид и т.п.
Однако всё это приводит к тому, что капитализм проходит через слабое состояние. Предстоящая (уже идущая, но только-только начинающаяся) мировая империалистическая война даст нам момент, когда мы снова сможем превратить её в войну гражданскую и снять с шеи паразитов.
как-то так
возьмем современный капитализм
количество предпринимателей — 1%
количество предпринимателей, дающих работу 95% работников — ещё в десять раз меньше
А не подскажете откуда взята эта статистика? В Германии половина работников заняты в средних и малых предприятиях(до 250 сотрудников).
По состоянию на ноябрь 2022 года в России зарегистрировано 5 908 615 компаний, которые относятся к малому, среднему бизнесу и к ИП. Последних среди них — 3 642 621, то есть на каждые сорок жителей России приходится по одному индивидуальному предпринимателю
то есть в 2022 у нас 2.5% предпринимателей.
Правда надо помнить, что такой всплеск предпринимательства связан не с тем, что у всех жилка проснулась, а с тем, что чуть ни насильно многих таковыми сделали: был человек таксистом, а потом ему сказали «если будешь самозанятым, то будешь меньший процент отчислять с каждого заказа». Ну и многие таксисты теперь — предприниматели (как ни смешно это звучит)
то есть в 2022 у нас 2.5% предпринимателей.
Вот именно что у вас. Но с каких это пор Россия стала эталоном и происходящее в ней стало можно просто брать и экстраполировать на весь мир? Или даже на весь "современный капитализм"?
а вторая половина?
А вторая половина либо самозанятые, либо работают на фирмы с больше чем 250 сотрудников. Но лично мне дальнейшую статистику искать лень. Для того чтобы опровергнут написанное вами достаточно того что есть.
не надо «либо» сколько предпринимателей среди второй половины?
А какая разница? Что это изменит в том что ваше заявление неверно? Но если вам интересно, то можете сами переводить:
https://de.statista.com/themen/4137/kleine-und-mittlere-unternehmen-kmu-in-deutschland/
https://de.statista.com/statistik/daten/studie/321958/umfrage/anzahl-der-kleinen-und-mittleren-unternehmen-in-deutschland/
https://www.ratgebermagazin24.de/die-vernachlaessigten-saeulen-der-gesellschaft-die-kleinen-unternehmen
ну один процент или два — разницы в данном контексте никакой
Ну там получается однозначно больше: "Более 80% из 3,5 млн немецких предприятий являются малыми предприятиями, в которых работает менее десяти человек." То есть даже забыть про самозанятых и считать что у каждого предприятия всего один хозяин-предприниматель(а часто это не так) и что в каждом из них работает ровно девять человек(что тоже совсем не всегда так), то всё равно получится больше чем 1-2%.
так сколько всего предприятий? 3.5 млн? а сколько население неметчины? 80 млн
4%? — унылое меньшинство
а сколько население неметчины? 80 млн
Я смотрю вы у нас мастер демагогии. Ну либо вообще не пытаетесь мозги напрягать. 80 миллионов это всё население. С пенсионерами, детьми и безработными.
А у вас уже так как 4% вместо 1% получилось. Да и то при worst case(ну то есть например часть из этих передприятий семейные и там все "предприниматели") :)
Те, у кого есть доступ к планированию, построят себе и своим детям дачи у моря. И потом возможно задумаются о базах на Луне.
Вы не создадите ничего уникального имея квадратно-гнездовое мышление.
А можно спросить, что вы создали уникального на промежутке последних, ну скажем, лет десяти? Только вот прям по-честному уникального, а не имеющего уже десяток аналогов.
На Java за последний 1 год
Заточенный под нужды организации менеджер обработки собщений из кафки с несколькими очередями, приоретизацией и многопоточной обработкой.
Интеграцию с платежной системой
На Delphi за последние 4 года
Графические компоненты для отрисовки карт местности
Компоненты для работы с базами данных (аналог Hibernate из мира Java)
Про дельфи не знаю, но неужели никто и никогда до вас не писал обработчиков для кафки и интеграций с платежными системами?
Отделяйте уникальность идеи от уникальности реализации.
Уникальных идей практически не встречается. Идея написать менеджер в общем то не уникальна, а вот уникальна реализация учитывающая особенности требований моего конкретного работодателя. Без фреймворков, ворованного кода и проч..модуль, реализующий функционал который нельзя найти в интернете хотя бы похожий. С платежными системами тоже самое. Они одни для всех организаций, идея тоже одна..но реализации не похожи и близко. Если вы пишете микросевис или прочую генерируемую на 50%-80% вещь, вам физически не хватит места что бы как то свою идею реализовать иначе чем ваш сосед по столу. В итоге откуда вам знать как можно писать код иначе если вы с самого входа в айти писали в рамках супержестких правил и генерации? Неоткуда..только если самому читать исходники людей которые писали все что придет им в голову, но откуда взяться мотивации читать чужой код если тут плаття неплохо да и куча других дел. Отсюда вывод: если у вас квадратно-гнездовое мышление или вас под него согнули вы уже с этим врятли что то сделаете, а релизовать полет фантазии вам негде да и взяться ему неоткуда.
Я правильно понял, если человек может написать интеграцию с платежной системой, значит, у него уже не квадратно-гнездовое мышление и есть полет фантазии? Тогда ладно, я за себя спокоен.
только если самому читать исходники людей которые писали все что придет им в голову
Доводилось мне читать такой код. Можно нинада больше?)
Неужели никто и никогда до Ребрандта не рисовал голых толстых баб? :)
который хорошо умеет только 1 функцию
Так-то методу divide et impera не один десяток лет. В том числе в разработке ПО
А прочитанный текст — в основном демагогия и манипуляции.
ну дык написанный вами - ещё большая демагогия.
по сути вы ничего не сказали.
микросервисы - организационная а не технологическая штука - это не опровергнуто
парсеры пишутся не только с goto - удивительно что это было бы не так. статья это не постулирует
и в общем всё как всегда в спорах с вашим ником - извините, но вы мне перестали быть интересны ещё в прошлых моих инкарнациях на habr
Не укажут мне теперь путь, увы и ах.
не укажут, демагогией заниматься неинтересно. Ваш ник - признак того, что она началась.
(ещё раз) заглянул в ваш профиль
у нас с вами большая разница: вы работаете на трендах, я работаю против них
поэтому вы смотрите на меня свысока: дескать что за быдло тут
ну а я смотрю на вас как на ничтожество.
ничего личного, просто констатация фактов
типы, разделение труда, как легализоваться в омерике итп
Типы в тренд вошли сильно после того, как я ими заинтересовался
вот опять вы не в силах разобраться с прочитанным
разве я хоть в одном месте написал о том, когда появились/вошли в тренд типы?
«Работаете на трендах» подразумевает, что что-то сначала становится трендовым, а потом этот работающий этим начинает заниматься
ухты! одно из моих предложений дошло до вашего мозга! круто! прогресс!
почему один? (глядя в ваш профиль) вы делаете это постоянно
Мне интересны граничные условия.
мне — неинтересны
граничные условия — всегда уникальны, по ним нельзя строить обобщения
Зато по ним можно проверять обобщения
наоборот. обобщения как правило делаются по среднестатистическому, по тренду итп. и в граничных условиях перестают работать.
потому проверять их тут, будете ну разве что вы
например описанный в статье — тренд на типизацию
тренд == поветрие
короче, нах иди, надоел
чтобы ссылаться на меня, ты сперва должен научиться читать, что я пишу. но, увы, у тебя пока с этим проблема
После этого оскорбления собеседника я о вас, в принципе всё понял. Держу пари, ваш разговор с начальником в статье был «немного» другим.
— Давайте вкорячим грязный хак в три продовых системы? Нет? А как же ТВОРЧЕСТВО.
А кто отвечать и поддерживать потом будет все это творчество вы так и не сказали. Карл Маркс? То-то и оно.
Как на быдло я смотрю только на тех, кто не умеет в аргументацию
неужели на себя вы смотрите как на быдло?
ни в жизть не поверю (опять просмотрел ваш профиль)
вариации на тему «нет ты»?
вы же иного варианта не приемлете, этот — хотя бы понимаете
ещё раз: монады — способ преобразовать лапшу из ада последовательных колбеков в нечто похожее на императив
чем монады отличаются от промисов? ТОЛЬКО ОДНИМ: промисы реализуют строго один (наиболее частый) паттерн, а монады — ажно четыре.
вот собственно и всё.
попробуйте осмыслить это
четыре ажно варианта: до первой ошибки, все варианты вообще, ну и так далее.
я понимаю, что трудно осилить, но попробуйте: чем монада от промиса отличается?
Разверните, пожалуйста, тему. Чем промисы сделаны неправильно и какого АПИ в них не хватает? Не ради дискуссии, реально интересно.
Ой, что ж тут делается-то, а?
варианты колбеков, вид сбоку
перестаньте совать всюду свой ацтойный язык, попробуйте например на JS написать аналог Монад.
кроме как с лямбдами у вас это не получится никак.
Я правильно понимаю, что если на каком-то языке $концепция не выражается нормальным образом, а выражается только через $костыль, то $концепция — это $костыль, вид сбоку?
неправильно.
ещё раз: берём питон с колбеками и промисами. потом питон делает шаг и добавляет операторы async/await и прячет колбеки под капотом.
вопрос: колбеки перестали существовать?
ответ: они никуда не делись, просто об однообразном оформлении теперь заботится интерпретатор
вопрос: после того как сделан такой шаг, нужны ли программисту монады?
ответ: нет, нафиг не нужны
как всегда неправильно
всё что можно сделать монадами можно делать и промисами. просто сложнее.
когда синтаксис промисов запихали под капот, эта сложность размывается и ни монады ни промисы не нужны
автоматически означает, что монады — подмножество промисов, просто с точки зрения их денотаций.
нет
если математическая библиотека поставляет четыре оператора умножить разделить сложить и вычесть
а другая — поставляет ещё и синус, то ни первая ни вторая не является подмножеством.
синус можно вычислить и с использованием первой и с использованием второй. просто во второй за вас это кто-то сделал запихав в соответствующую функцию.
новой парадигмы вторая библиотека не несёт. — это центральный тезис
Промис — частный случай монады, не наоборот
ну вот, наконец-то! именно так. промис покрывает 95% необходимостей возни с колбеками. кому-то захотелось покрыть оставшиеся 5 — наваяли фигню, назвали монадами.
в языке где есть файберы или корутины ни монады ни промисы становятся нафиг не нужны
На каких трендах?
Салтыков-Щедрин:
Чего-то хотелось: не то конституции, не то севрюжины с хреном, не то взять бы да ободрать кого-нибудь.
>общая вовлеченность в процесс остается на уровне ниже плинтуса
В том числе и поэтому. Если процесс совершенствуют только избранные, а не все, если вовлеченность на нуле — ни к чему хорошему это не приведет.
А какое отношение способ деплоймента и комуникации (микросервисы) имеет к процессу разработки, и уж тем более как ограничивает его. Можно просто с такой же уверенностью сказать, что мэйкфайлы (или пакетирование) ограничивают.
Я всегда пишу код и стараюсь писать так, чтобы "испольнителей можно действителньо менять по щелчку пальца" и причин на это более чем достаточно
Во-первых, это показатель хорошей декомпозии и понятности кода.
Во-вторых, я, как исполнитель, меняюсь каждый день. Узнаю что-то новое, забываю что-то старое, бываю без настроения, бываю с настроением и т.д.
В-третьих, если все будут создавать места, где исполнителей можно менять по щелчку пальцев, то будет еще легче менять работу. Тебя заменили по щелчку пальцев? Не вопрос, найди где кого-нибудь заменят по щелчку пальцев на тебя, а он в свою очередь тоже такое место найдет. Хорошо же, ну?
Да-да-да. Марксизм в натуральном виде.
https://www.marxists.org/russkij/marx/1867/capital_vol1/29.htm
"...Машинный труд, до крайности захватывая нервную систему, подавляет многостороннюю игру мускулов и отнимает у человека всякую возможность свободной физической и духовной деятельности[707]. Даже облегчение труда становится средством пытки, потому что машина освобождает не рабочего от труда, а его труд от всякого содержания. Всякому капиталистическому производству, поскольку оно есть не только процесс труда, но в то же время и процесс возрастания капитала, присуще то обстоятельство, что не рабочий применяет условно труда, а наоборот, условие труда применяет рабочего, но только с развитием машины это извращённое отношение получает технически осязаемую реальность. Вследствие своего превращения в автомат средство труда во время самого процесса труда противостоит рабочему как капитал, как мёртвый труд, который подчиняет себе живую рабочую силу и высасывает её. Отделение интеллектуальных сил процесса производства от физического труда и превращение их во власть капитала над трудом получает своё завершение, как уже указывалось раньше, в крупной промышленности, построенной на базе машин. Частичное искусство отдельного машинного рабочего, подвергшегося опустошению, исчезает как ничтожная и не имеющая никакого значения деталь перед наукой, перед колоссальными силами природы и перед общественным массовым трудом, воплощёнными в системе машин и создающими вместе с последней власть «хозяина» (master). ..."
Есть надежды на «тёмный цех» — что совсем устранит необходимость в однообразном труде. Но глядя на всё растущую коприрастию появляются опасения, что это будет просто переход на следующий круг…
Мастерам - место в новых разработках и работе над прототипами.
Это проблема, розы выточенные на станке не нужны.
У нас есть механик в лаборатории (токарь-фрезеровщик-всё-в одном лице), так после того как мы купили ЧПУ - мы его напрягаем значительно реже.
А что такое "темный цех"?
Вы напрасно считаете пассаж смешным. Маркса волнует состояние человека, а не прогресс цивилизации. Труд действительно постоянно деградирует, становится все более не-человеческим.
Рекомендую для подробного изучения работу Гарри Бравермана "Труд и монополистический капитал: деградация труда в XX веке"
Прогресс цивилизации и влияет на состояние человека, причем влияет позитивно. Со времен Маркса люди стали работать существенно меньше, а благ потреблять намного больше. "Труд деградирует и становится нечеловеческим" это просто демагогия. Труд это работа, которую совершают люди для блага других людей. Он человеческий по определению.
Со времен Маркса люди стали работать существенно меньше, а благ потреблять намного больше.
так скажем — далеко не все
Со времен Маркса люди стали работать существенно меньше, а благ потреблять намного больше.
Шутка в том, что не последнюю роль в этом сыграла именно борьба рабочих за свои права. И марксизм в том числе, как теоритическая основа для всякого рода социалистов и социал-демократов.
Труд это работа, которую совершают люди для блага других людей. Он человеческий по определению.
Имеется в виду, что рабочий, который по 12 часов в день совершает на конвецере однообразные действия (например, перекладывает деталь от одного станка к другому), занимается тяжелым отупляющим трудом, становясь живым винтиком в конвейере.
Такой труд не оставляет места для творчества, скорей всего вреден здоровью, и угнетающе дейтвует на живого человека.
По крайней мере так оно было во времена Маркса. И скорей всего, встречается и сейчас, особенно там, где дешевая рабочая сила.
занимается тяжелым отупляющим трудом
Тяжёлый отупляющий труд придуман очень сильно задолго до капитализма. Механизация делает тяжёлый труд легче - до капитализма это было не востребовано. А что не везде есть место творчеству.. Так и люди разные. Можно креативно убирать снег с дороги, можно лечить людей строго по протоколу.
Если вы не поняли идею, переформулирую: сам труд все больше не соответствует психике и физиологии человека, например, требует от него постоянной концентрации внимания и быстрой реакции, заставляет делать однообразные движения, не дает чувства сопричастности и смысла.
Труд действительно постоянно деградирует, становится все более не-человеческим.Ну да, что за работа у экскаваторщика сейчас — сиди, рычажки дергай, сплошная деградация. Зато вот раньше — лопату в руки, мышцы играют — чистейшее творчество и креатив!
Раньше - это во время промышленной цивилизации, но без экскаватора, или все-таки раньше, когда человек строил себе дом сам? В последнем случае, это реально было творчество и креатив, даже с лопатой в руках.
Боюсь, что вы вообще не понимаете, о чем речь.
В последнем случае, это реально было творчество и креатив, даже с лопатой в руках.А Вы точно захотите жить в доме, который может построить человек без специализации строителя и без современных технических средств?
Боюсь, что вы вообще не понимаете, о чем речь.Путь развития цивилизации — это путь специализации, все более и более узкой и глубокой, потому как объем знаний в каждой сфере постоянно растет. Да, человек может быть одновременно и строителем и врачом и еще кем-то, но чем более широкая сфера, тем хуже его знания и навыки в каждом из направлений, просто потому, что необъятного не объять. Поэтому в развитых странах строит один, отделывает другой, электрикой занимается третий и так далее.
А Вы точно захотите жить в доме, который может построить человек без специализации строителя и без современных технических средств?
А вы точно поняли, что речь в моем комментарии идет не о проблемах потребителя, а о проблемах непосредственного производителя?
Путь развития цивилизации — это путь специализации, все более и более узкой и глубокой
...И в конце этого пути мы получаем "Первых людей на Луне" Уэллса. Ну или "Геном" Лукьяненко, если хотите.
А вы точно поняли, что речь в моем комментарии идет не о проблемах потребителя, а о проблемах непосредственного производителя?А кому нужен такой производитель, для которого проблемы потребителя не на первом месте? Уже проходили это «жри чо дали», опять забег по тем же граблям устраивать?
Себе он нужен. Вы же не пытаетесь оправдать рабство, я надеюсь?
Но я не только работник, но и потребитель услуг и товаров произведенных другими людьми. И как потребитель я заинтересован получать качественную услугу по доступной цене, а не хоть что-то за бешеные деньги, потому как производитель вот такой супер одухотворенный и ему только творчество интересно, а не мои проблемы.
А как работник в чем вы заинтересованы?
И да, в разное время и разных обстоятельствах человек может выбирать сильно разное — кто-то временно готов пахать на износ чтобы решить текущие проблемы, а кто-то наоборот уже все решил и предпочтет расслабленно делает мелкие проекты пару часов в неделю на фрилансе.
Пока есть конкуренция на рынке — такой выбор будет.
Раньше - это во время промышленной цивилизации, но без экскаватора, или все-таки раньше, когда человек строил себе дом сам? В последнем случае, это реально было творчество и креатив, даже с лопатой в руках.
Да, и раньше. Вот тебе поле, вот мотыга, херач отсюда и до заката. Такой креатив, что обделаться надо.
Сразу видно городских теоретиков. Вы б на своих 6 сотках хотя б годик повпахивали с лопатой - сразу б по-другому запели.
На мой взгляд, эта цитата вырвана из контекста (вообще Маркса, как и многих других философов, цитировать сложно) и потому создаёт не совсем верное впечатление об отношении Маркса к технологиям и выставляет его противником машин как класса :)
Если говорить о технологиях, то философия Маркса (детерминизм) как и классичесая философская эпохи Просвещения (инструментализм) характерны нейтральным отношением к задачам и целям технологии, те воспринимают её как нейтральную силу находящуюся на службе человека (в отличие от Субстанциализма Хайдегера или Критической теории). Разница состоит в том, что в основе инструментализма лежит идея о превосходящем влиянии людей и общества на развитие технологии, т.е. считается контролируемой силой, а детерминизм считает наоборот и видит в развитии технологии первичную силу меняющую общество.
Инструментализм можно описать фразой "не оружие убивают человека, а человек убивает человека", т.е. "смысл" в инструмент вкладывается уже обществом, и для того, чтобы поменять сценарии использования инструмента, надо поменять общество. Детерминизм при этом считает, что надо уже на этапе дизайна инструмента задумываться о том как появление именно такого инструмента с такими характеристиками повлияет на развитие общества. Т.е. идеи Маркса про фабрику не о том, что все машины надо срочно отменить, а о том, что дизайн любой автоматизации фабрики должен брать во внимание в том числе и то как это скажется на качестве и количестве рабочих мест после её внедрения.
да, он говорил, что технологический уровень влияет на то, как построено общество, но чтобы прямо таки детерминизм?
По мне так, любой человек, окончательно признавший детерминизм — навсегда теряет смысл своего существования, перестаёт быть человеком, ну и уж точно никогда не станет великим философом :)
Во многих идеях философия Маркса совпадает с философией детерминизма хотя бы потому, что работы Канта были значительной базой на которую опирался Маркс. Но конкретно в данном случае речь идёт именно о том, что в философии Маркса технологии формируют(определяют, determin) общество и ценностям которым они служат.
Если мы сконцентрируется только на инструментализме и детерминизме, то, упрощённо (очень грубо), разница будет следующей. У общества есть система ценностей, любой инструмент, который мы создаём для служения этим ценностям по умолчанию нейтрален и просто инструмент. Далее, мы применяем этот инструмент на практике и он начинает ломать ценности, которым должен служить. В идеях инструменталистов - либо не тот инструмент, либо не правильно применяли, либо не туда куда нужно. В идеях детерминизма - задизайнили изначально неверно и в дизайн надо было закладывать ту систему ценностей, на службе которой инструмент должен стоять.
Материалистическая диалектика действительно есть детерминистическая теория. Вероятно это для вас новость, так как вы глубоко не пытались понять Маркса.
"Всему есть объективная причина" - так можно кратко охарактеризовать это мировоззрение. Оно детерминистично.
А я бы послушал про историю с топ менеджером с точки зрения топ менеджера. Что то в этой былине явно приукрашено.
PS: Микросервисы действительно помогают масштабироваться если умеешь делегировать и распределять труд.
Предполагаю что он решал свои задачи: набрать людей, дать ответственное задание сократить издержки. Тут пахнет гигантской ответственностью и премией.
Все описанное - не задачи топа, его задачи - определить стратегию, задать тренд и получить вменяемые отчеты о результатах от аналитиков.
А я бы послушал про историю с топ менеджером с точки зрения топ менеджера. Что то в этой былине явно приукрашено.
Тут недавно была статья - взгляд с другой стороны, выводы там другие, но плач Ярославны о том что в нанимаемых сотрудниках отсутствуют необходимые качества, типа ответственности, присутствует:
https://habr.com/ru/post/709516/
Просто история рассказана с точки зрения разработчика (скорее всего очень молодого), который ситуацию дальше "50 строчек кода", который он "может написать за день". Между тем этот код кому-то еще надо потом тестировать, кому-то собирать и развертывать, и кому-то мониторить и сопровождать. И у всех этих "кому-то" вся их существующая инфраструктура может быть (даже скорее всего) уже заточена под определенные шаблоны в которые "написанные за день 50 строчек кода" не влазит.
Так в это же и прикол. Все ограничения, техаудиты, и прочая херь рассчитана на код, который будет годами работать, поддерживаться.
А автор хотел сделать разовый проект, решить задачу, и потом его выбросить.
Для первой задачи, да, микросервисы затыкают массу дыр. Для второй создают проблемы.
А теперь вопрос, почему не иметь сразу 2 шаблона? Один для Кода с большой буквы, который на годы. Второй для разового маленького кодика на выброс? Лично моё мнение, что потому, что это откроет ящик пандоры. Если такое разрешить, то любой новый проект будут пускать по ветке 2, ибо продакт хочет бонус и медальку, а не ждать 4 года. И, вполне может выйти, что через какое-то время весь новый код будет формально считаться кодиком на выброс ради скорости разработки. Думаю, что очевидно, чем это закончится.
Причем если посмотреть "свыше" (а автор ведь говорит не про одну компанию, а в масштабах "мировой революции"), то рыночек отлично решает. Мы тут можем теоретически разное фантазировать, о том как надо или как не надо (не понимая деталей проекта), но очевидно же более общее правило: Как только яндекс будет неэффективно управлять своей службой такси (по любой причине) - на свободном конкурентном рынке тут же открывается ниша, где служба такси может все делать эффективнее и дешевле. И там, где у неэффективного яндекса поездка стоит 500р, у той службы она будет 200р. Потому что у них goto и эксепшены и сервисы правильные. А если же при правильных эксепшнах у них поездка все равно стоит 480р - то так ли важна эта проблема?
Что на практике подешевело в РФ по сравнению с 2000 годом, благодаря конкуренции именно на российском рынке? Телекоммуникации и западную электронику, естественно, исключаем.
Современная Россия как эталон для демонстрации рыночных механизмов? Нам до свободного рынка, демократии и капитализма еще оочень далеко. А то, что вы исключили (например, западную электронику) подешевело как раз потому, что там конкуренция есть.
Добавлено:
А вот разве как раз такси - не подходит?
Вообще, вы интересно задали вопрос: "кроме зарубежной электроники" (равносильно, кроме любой). И тут две мысли интересных возникли:
Если мы практически все импортируем - то что может у нас подешеветь? Если и подешевеет, то потому что там подешевело.
Мне кажется, очень часто из-за конкуренции не дешевеет, а изначально дешево. Ну вот выходит какой-нибудь новаторский смартфон, в какой-то мере он уникальный (первый смартфон с NFC, например). Но через месяц выйдет конкурент. Поэтому первый смартфон исходно стоит так, чтобы конкурировать с тем, кто только появится в будущем. Поэтому и дешеветь особо не приходится.
Хз, на примере Intel/AMD прямо видно, как цены снижаются после выхода И бенчмаркинга конкурентов.
Вообще-то в РФ - капитализм, причем можно сказать, эталонный. Критерий любой экономической деятельности - прибыль. Критерий неэкономической деятельности (медицина, госуправление, образование) - тоже прибыль. Какой еще вам капитализм нужен?
Что же касается "свободного рынка", то еще неизвестно, правило ли он или исключение.
Каким образом демократия к экономике - вообще неясно.
В России - госкапитализм, да еще и коррупционный, без равенства перед законом, без контролируемой и сменяемой власти. Мне кажется, вы капитализмом считаете любой бардак, но чтобы создать капитализм - надо еще работать.
Про белорусские креветки слышали же? Вот в капитализме их не бывает. Либо все возят креветки на равных словиях (в идеале), либо никто. В капитализме не оказываются миллиардерами случайные друзья по дзюдо. Это крайне, крайне маловероятное совпадение.
Демократия к экономике очень даже прямым образом. Вот одна не очень демократическая страна сейчас служит прекрасной иллюстрацией, что деньги из нее надо вывозить сейчас, и всегда надо было вывозить,а владываться в бизнес в ней - очень глупо.
В России — госкапитализм, да еще и коррупционный, без равенства перед законом, без контролируемой и сменяемой власти
взять Китай: там государство владеет (в процентах) большим количеством собственности чем Россия. Выглядит это неплохо.
взять США: там коррупция значительно более развита, а местами даже легализована. И ничего. Значительную часть мира строит.
В капитализме не оказываются миллиардерами случайные друзья по дзюдо.
в капитализме именно так всё и оказывается. друзья (реже) или родственники (чаще).
Вот в списке литературы в статье есть произведение Джека Лондона, крайне рекомендую почитать.
Демократия к экономике очень даже прямым образом
вообще никак.
Китай? Ну вот и приведите любой пример успеха из Китая, только посмотрите всего лишь на 1 шаг глубже, на причины этого (опишите эти причины, как я ниже сделал, причины помогают отличать то, что сделано "благодаря" от того, что сделано "вопреки").
Например, вот для России приведу вам пример. Я отчасти фрилансом зарабатываю (одиночка), отчасти небольшой частный бизнес (небольшая команда). Я сам научился новым технологиям. Сам нашел заказчика. Сам обсудил с ним условия работы, деньги. Выполняю работу. Получаю деньги. Часть денег - отдаю государству. Государство за меня ничего не сделала в этом плане (разве что дало некоторые налоговые льготы на первое время - то есть, так же, собирало с меня деньги, только чуть меньше). Но главное - не помогало. Ни один рубль мне не упал на счет от государства.
Какова роль государства в моем бизнесе? (я могу даже найти конкретные даты и номера указов-законов). Закон о свободе частном предпринимательстве. Закон о внешней торговле (они разрешили мне работать).. Закон о банковской деятельности (благодаря ему я могу переводить деньги. Но переводит мне их другой бизнесмен, банкир, а государство просто разрешает нам, всего лишь не бьет нас палками за это - ну и за то спасибо). Закон об отмене цензуры (иначе, какой интернет может быть?). Везде в моем бизнесе я вижу мой труд и труд других людей (бизнесменов). А упомянутые законы приняты в те самые легендарные "девяностые". С 2000 у меня на виду только один полезный закон - отменены разрешения на мобильные. (Но это опять же, государство не помогло, а перестало мешать). Так что, я знаю, кому в государстве я благодарен, и в какие даты эти действия произошли.
С интересом послушаю, как именно руководящая роль коммунистической партии Китая помогает Xiaomi делать смартфоны и почему их нельзя делать без помощи Партии.
Про легализованную коррупцию, простите, но это оксюморон. У вас какой-то свой, особенный, смысл вложен в это слово.
Какова роль государства в моем бизнесе?
примерно такая же как если бы вы открывали бизнес в другом государстве. отличий почти нет.
ну разве что вести бизнес в России гораздо проще чем, скажем, в любой европейской стране.
хочешь таксовать? ~5000 лицензия и вози себе пассажиров. в Париже такая лицензия до 250 тыс евро добирается (у них там что-то вродь аукциона/рынка лицензий)
хочешь на газельке перевозить грузы? Скажем мебель переезжающих людей. регаешь ИП и возишь. упрощёнка или не упрощёнка или даже самозанятость + ИП (без расчётного счёта — вообще бесплатно).
оформляется за день, расходы минимальны.
в США подобный бизнес потребует обязательные расходы на страховку (помимо госпошлин/налогов как у нас) начинающиеся от 50 тыс $ в год.
хочешь в германии IT-автоматизацию транспорта запустить? правительство может попросить тебя, ну скажем, построить фонтан в городе. А если не построишь — могут и не одобрить разрешение на занятие бизнесом.
и так всё
PS: всё перечисленное — это из моего опыта. много занимался автоматизацией средств транспорта, ну и близко с этим сталкивался.
Ну вот вы привели примеры как разные ограничения от государства мешают бизнесу. Но где же в этом помощь, тем более конкретный китайский пример?
я воспринял ваш текст как жалобу на то, что "в России не оч хорошо", ну и рассказал о своём опыте по другим странам. там всё гораздо сложнее.
чтобы государство именно помогало чем-то заниматься, надо, увы, заниматься чем-то значимым для государства. Это опять же общее для всего мира правило. Россия тут не лучше/не хуже прочих
Это хорошо, что там сложнее: значит, бизнесы сворачиваются там, и переезжают к нам. Бизнес ведь не дурак, он денежки считать умеет.
Как по мне, государство не должно помогать (кроме, может, каких-то исключительным случаев, которые не надо путать с правилом). Оно должно создавать условия для равной конкуренции и стараться не мешать. Откатываемся на самое начало ветки про конкуренцию. Если завтра я открываю свою службу такси, задача государства, чтобы я мог открыть ее легко, быстро, дешево. И чтобы гипотетические хулиганы от яндекса мне ноги не переломали и машины не сожгли. (То есть, устанавливать и поддеживать закон). Все. А писать мессенджеры, службы такси, делать банки, газеты, телеканалы и печь булочки - должны уже сами люди.
Как по мне, государство не должно помогать
как по мне так должно.
Оно должно создавать условия для равной конкуренции и стараться не мешать
как может появиться региональный конкурент Google? если без господдержки? никак.
как может появиться скажем производитель медицинского оборудования, при том, что импортное всяко дешевле?
вот кстати интересный бизнес, который государство поддержало, считаю что таких должно быть больше
А почему вы не хотите чтобы инвестициями занимались (только не смейтесь сразу, понимаю, что крайне радикальную вещь скажу): ... инвесторы?
Конкурента гугла создавать не надо, он уже есть - поисковик спутник. Все как вы и хотели, с господдержкой. Разве не счастье? Или вы хотите еще спутник-2, спутник-3, и все это на мои деньги (мой бизнес не просит у гос-ва), пока я совсем не сдохну?
А почему в России производить, скажем, медоборудование дороже, чем в швейцарии? Швейцарцу нужно платить 7000 долларов в месяц, русскому 1000 долларов в месяц. Почему швейцарские медицинские компании до сих пор не переехали в Россию, что они говорят?
а потому что это не работает.
> А почему в России производить, скажем, медоборудование дороже, чем в швейцарии? Швейцарцу нужно платить 7000 долларов в месяц, русскому 1000 долларов в месяц. Почему швейцарские медицинские компании до сих пор не переехали в Россию, что они говорят?
я представьте знаю почему. приблизительно году в 2003-2004 я работал в компании, которая разрабатывала то самое медоборудование. мы делали софт для агрегата автоматически разбирающего кровь на фракции и делающего какой-то набор анализов.
так вот, стоил этот агрегат — жалкие сто баксов на те деньги, конкуренты (швейцарские и проч) стоили условно двести, но-но-но…
швейцарским и проч… не требовалось лицензирование, а нам требовалось. и чтоб отбить только официальную стоимость лицензий, ну никак не получалось продавать девайс дешевле пятисот баксов.
в итоге — эта разработка ушла на завод в литве и сейчас, до сих пор, в Россию (насколько знаю) продаётся от имени иностранного бренда.
а всё почему? а потому что какие-то кретины в своё время как раз принимали всякие тупые законы на тему «чем свой производитель, лучше импортный»
какие-то кретины в своё время как раз принимали всякие тупые законы
Кретины - они же не с Марса прилетели? И законы пишутся не просто от фонаря, а с какой-то целью?
в результате проигранной войны всегда у власти становятся кретины. это закон природы
> И законы пишутся не просто от фонаря, а с какой-то целью?
хорошо хоть ЛГБТ не успели легализовать, а то и это пришлось бы расхлёбывать
это закон природы
Нет такого закона ;)
хорошо хоть ЛГБТ не успели легализовать, а то и это пришлось бы расхлёбывать
А что такого несправедливого в ЛГБТ? Они как-то по особенному относятся к отчуждению результатов труда?
во-вторых, это просто омерзительно
в третьих, их цель (одна из) или смысл жизни — сообщать всему миру о своих перверсиях,
пруф и цитата:
Википедия:
каминг-аут как процесс, который важен для психологического здоровья гомосексуалов
то есть избавиться от них, предоставив им свободу заниматься друг дружкой, нельзя: для их «психического здоровья» им требуется, чтобы они постоянно всех вокруг информировали о том кто они
в четвёртых: это крайне агрессивная секта. если ей не давать укорот, то ещё с глубокой древности имеются свидетельства (которым более 3000 лет), что кончается это тотальной диктатурой ЛГБТ. Остановить подобную диктатуру возможно только силовым способом.
И пришли те два Ангела в Содом вечером, когда Лот сидел у ворот Содома. Лот увидел, и встал, чтобы встретить их, и поклонился лицом до земли. И сказал: государи мои! зайдите в дом раба вашего и ночуйте, и умойте ноги ваши, и встаньте поутру и пойдете в путь свой. Но они сказали: нет, мы ночуем на улице. Он же сильно упрашивал их; и они пошли к нему и пришли в дом его. Он сделал им угощение и испек пресные хлебы, и они ели. Еще не легли они спать, как городские жители, Содомляне, от молодого до старого, весь народ со всех концов города, окружили дом и вызвали Лота и говорили ему: где люди, пришедшие к тебе на ночь? выведи их к нам; мы познаем их.
их современная агрессивность подтверждается и тем, что они творят в школах на западе. Уже добрались до смены пола детям 4 лет!
впрочем это всё офтоп.
PS: Если хочется потролить на тему коммунизм и святые писания, то огорчу: как источник знаний коммунисты их не отрицали.
Как всё запущено то оказывается...
их современная агрессивность подтверждается и тем, что они творят в школах на западе. Уже добрались до смены пола детям 4 лет!
А можно пруф? Только не из соловьёв-ТВ, а первоисточник, чтобы хотя бы на западном языке ;)
Жаль, пруфов не будет :( Значит, это всё выдумки? Фу, как некрасиво..
и пруфы про 4летнего и пруфы про смены пола в школах и большое интервью одного отца, не согасившегося с тем чтобы его несовершеннолетняя дочь сменила пол (по решению школьного психолога), которого за это несогласие посадили (кстати это интервью брали канадские журналисты и оно есть как на русском так на английском). В общем пруфов полно. Здесь, думаю не стоит дальше википедии ходить. Всё-таки это IT ресурс.
во-вторых, это просто омерзительно
Это ты омерзителен. Ничего личного, просто констатация факта.
Браво ;) Прямо как в известном анекдоте:
"Предлагаю расстрелять всех евреев и велосипедистов! - А велосипедистов за что?! - Я знал что по евреям у вас возражений не будет"
У меня есть возражения по расстрелам, но в вашей картине мира без этого никак.
или вы о том, что Гитлер (по данным ЦРУ) сам был ЛГБТ и это ещё один пример того, что если ЛГБТ не давать укорота, то они причинят миру безумный вред. Поясните?
А так-то да, это ещё одно подтверждение того, что это движение нужно ограничивать.
Один гомосексуалист, дорвавшийся до власти и… семьдесят миллионов жертв!:
Адольф Гитлер был бисексуалом, а также имел садомазохистские наклонности, говорится в отчете, подготовленном для президента США Франклина Рузвельта в 1943 году и рассекреченном в наши дни ЦРУ. В юности будущий фюрер проживал в мужском общежитии в Вене, куда состоятельные пожилые господа приходили для удовлетворения сексуальных желаний с молодыми красивыми парнями. Из документов ЦРУ следует, что Гитлер, возможно, имел любовную связь со своим помощником Рудольфом Гессом.
Лидер нацистской Германии Адольф Гитлер сочетал в себе гомосексуальную и гетеросексуальную ориентации, а также имел садомазахистские наклонности (https://www.cia.gov/readingroom/document/cia-rdp78-02646r000600240001-5), следует из рассекреченных материалов (https://www.cia.gov/readingroom/) ЦРУ, составленных в 1943 году для президента США Франклина Рузвельта.
В 70-страничном докладе также сообщается о сексуальном влечении фюрера к своему заместителю Рудольфу Гессу, который являлся трансвеститом, был известен в соответствующей среде под прозвищами «Фрейлин Анна» или «Черная Эмма» и имел обыкновение одеваться в женскую одежду. В ЦРУ не исключают сексуального контакта между ними во время отбытия тюремного заключения в 1920-е годы.
...
вроде в подветке об ЛГБТ о расстрелах пока ничего не было?
Пока не было ;)
Один гомосексуалист, дорвавшийся до власти и… семьдесят миллионов жертв!:
Давайте не так. Один художник, дорвавшийся до власти.. Этим художникам если не давать укорота, они причинят миру безумный вред. Всё правильно? ;)
Хотя может причина не в том, что он художник, а веган? Этим веганам, если не давать укорота...
Так выходит, проблема в государстве? (оно плохие законы приняло). Но вместо того чтобы исправить плохие законы, вы хотите еще больше извратить ситуацию, и сделать чтобы какие-то кретины еще и инвестициями занялись?
это только в стране эльфов плохие законы исправляются по щелчку пальцев. А в реальном мире, плохие законы потребны плохим людям для обогащения, а капитал, стоящий за этими плохими людьми настолько огромен, что может смести не только того, кто пытается заменить плохое хорошим, но и вообще всю страну.
отсюда и войны, организованные этим капиталом
Но где же в этом помощь, тем более конкретный китайский пример?
с Китаем близко не сталкивался, вы, приводя свой бизнес в пример ведь хотели перевести на близкое сравнение? Не могу сказать ничего.
про Китай мы видим только макроэкономические показатели ежегодного развития, которые гораздо лучше многих прочих стран.
при этом, хоть Китай и называют "тоталитарным", а, например, количество зеков там и в абсолютных цифрах (sic!) и в относительных меньше чем скажем в "свободных" США.
Кто знает, может быть это как раз следствие приближенности политики государства к среднему человеку? Почему в США так много преступников, что они вынуждены держать по тюрьмам больше народу чем впятеро больший по населению Китай?
В Китае - своя "нефть". Их нефть - дешевая рабочая сила (огромное ее количество). Причина их успеха - то, что они приоткрыли (дали свободу) рыночные возможности для работы (выгоднее рыбу от берегов Великобритании везти в Китай, там чистить за копейки, и везти обратно). Плюс, еще где-то с 1970-ых годов распространились дешевые контейнерные морские перевозки (кстати, технология Docker как раз это обыгрывает в своем названии). Именно поэтому возить товары в Китай и из Китая стало дешево.
По мере того, как уровень благосостояния там растет (а расти с низкой базы - достаточно легко) - эта модель бизнеса потихоньку иссякает, уже не хотят чистить рыбу за цент, хотят уже за доллар. И уже приходится что-то думать (аутсорсить в более бедные страны или же механизировать или же возвращать работу своим работникам - к ним хотя бы везти быстрее и дешевле).
Но главное - никакого чуда централизации и тотального контроля там нет. Все всегда и везде создается через свободу (через то, что поводок там чуть-чуть приотпустили).
Если вы видите одновременность события А и какого-то фактора Б, надо понять, это А свершилось благодаря Б или же вопреки Б, установить причинно-следственную связь, а не выдумать ее просто на основании какого-то совпадения. "Моргенштерн выпустил новый хит, вышел новый процессор от Интел - слава Моргенштерну!"
такой "нефтью" обладают сотни государств по миру, а вот рост только у Китая.
выходит дело не (только) в нефти?
Конечно. Любой ресурс имеет свою потенциальную максимальную стоимость и реальную. Потенциально - Китаец не хуже швейцарца, мозга у него не меньше, рук тоже. Значит, теми же руками по той же технологии может делать тот же "швейцарский" товар (И у него получится именно швейцарский, в смысле качества. А не китайский). Значит, китайцы могут ориентироваться на медианную ЗП в 7000 долларов. Насколько сейчас недотягивает Китай до этой цены - вот столько и обходится им "руководящая роль компартии".
И Китай - не худшая страна на планете, есть страны, где тоже люди есть, у них тоже 1 голова и две руки, но условия для бизнеса и инвестиций там еще хуже, да.
Так вы же не из будущего прилетели?! Про то каким путем шел Китай и к чему пришел — мы скоро узнаем.
Принесли суровым сибирским лесорубам японскую бензопилу
ну-ка, — сказали лесорубы и подсунули ей дуб
вжж! — сказала бензопила и распилила дуб
хгм, — сказали лесорубы и подсунули ей бетонную шпалу
в-жжжжжггггррр! — сказала бензопила и сломалась
то-то же! — сказали лесорубы и отправились валить лес традиционным способом
Китай может и опрокинут: подкупив ли элиты, прямым ли военным столкновением, опрокинув ли Россию и заблокировав Китаю все доступы к ресурсам.
если человека убивают ударом кирпича по голове, то факт убийства ничего не говорит о вредности того образа жизни, которого он придерживался
вы капитализмом считаете любой бардак
Я считаю капитализмом ровно то, что написано в любом учебнике политологии, включая западные. Капитализм - это экономико-политическая система, в которой главным критерием экономической деятельности является прибыль. РФ прекрасно под это определение подходит, даже с избытком.
Если вы считаете капитализмом только райские рекламные картинки, то это исключительно недостатки вашей когнитивной картины мира.
Похоже, в мире более одного учебника, и в них даже немного разные определения...
Покажите ваш учебник.
Из самых популярных - википедия. Причем определяющим там является первое предложение (про равенство, собственность, итд) - так как оно видимое, его можно проверить. А второе (про главный критерий), мне кажется, вообще лишнее, ненужное пояснение, оно про психологию (а чужая душа - потемки). Откуда нам знать, больницу открыли потому что хотят спасать людей, или потому что желают подло наживаться на болезнях. :-)
Вот в капитализме их не бывает. Либо все возят креветки на равных словиях (в идеале), либо никто.
Вы написали ерунду. Заградительные пошлины и другие меры ограничения импорта применялись в самых что ни на есть капиталистических странах, причем постоянно и активно.
Более того, именно с помощью таких мер развитые страны и строили собственную экономику.
Для вашего дальнейшего просвещения: https://www.amazon.com/Bad-Samaritans-Secret-History-Capitalism/dp/1596915986
Откройте любой учебник политологии, можно западный. И прочитайте определение.
P.S. Больше всего свобод было в первобытном обществе.
Меня вполне устраивает сжатое определение из Википедии:
Capitalism is an economic system based on the private ownership of the means of production and their operation for profit
Так Яндекс Такси ведь монополист на рынке, и другие, "более эффективные" компании он наверняка сможет выдавить нерыночными методами.
А автор хотел сделать разовый проект, решить задачу, и потом его выбросить.
А автор не думает, что без "все ограничения, техаудиты, и прочая херь" его разовый проект может обвалить кучу всего другого и принести больше убытков чем должен был бы принести выгоды?
Разовый код годится там, где кроме тебя и еще полутора калек его никто не использует и от него ничего больше не зависит.
Он расскажет о гигантской сложности систем и куче связности, которую можно победить только микросервисами.
Потому что менеджер тем важнее, чем больше у него людей в подчинении. Если он упростит архитектуру и оставит 15-20 человек вместо 150, то его политический вес в компании сократится в примерно во столько же раз.
А регламенты ему помогают бороться с теми, кто может работу сократить.
Всю статью, похоже, надо в раздел "юмор".
необоснованное суждение "о вредности оператора goto"
Пишу на C# c 2005 года, недавно поймал себя на том, что не могу вспомнить а есть ли там оператор "goto" вообще. Даже в документацию полез из любопытства. (Оказалось, что все-таки есть).
Заставьте творца, который живёт внутри, выйти на первый план!
За 15+ лет разработки уже з*ся половину если не больше рабочего времени не работать, а разбираться во всевозможном творчестве творческих творцов.
Я понимаю, что для перекидывания 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-м файле.
Человеку свойственно хейтить то что он не понимает/не умеет пользоваться. Возможно оператор goto просто не для всех. Я использовал его буквально пару раз в своей жизни, и не считаю его чем то из дьявольских вещей, но общество видимо склонно округлять и срезать уточнения получая цепочку "оператор goto выручает, но если вы будете использовать его неосторожно получите по лбу" => "goto бьет людей" => "goto не должен существовать". Последней стадией начинается плохое отношение и отлучение от процесса раработки тех кто его использовал успешно или просто нейтрально к нему относится.
на бейсике активно им пользовались, и вроде смотрелся он там весьма органично )
а в более поздних языках его заменили конструкциями типа break, continue, case и тп )
Конечно он нужен, как нужно многое другое из неиспользуемого, точнее из не часто используемого. Важно, чтоб каждое применение было осознанным и ожидаемым.
Получается ещё во времена Дейкстры была проблема с творцами со стремлением захламления кода, когда кажется, что лучше совсем запретить, чем дождаться момента невозможности использования.
Конкрентно по вашей ссылке, очень легко понять зачем там нужен goto(по первым 10 штукам по крайней мере), по сути это и есть один из вариантов правильного его использования, еще вариант правильного использования на мой взгляд - это выйти из вложенного цикла, хотя иногда для этого есть отдельный механизм в языке.
боль от использования такого "плохого" инструмента
Вроде автор коммента ругает не goto, а призыв к творчеству а коде, в целом не случайно придумали линтеры и прочие штуки для стандартизации, не очень приятно в коде видеть имена переменных типа таких _Cammel_caseVar_DATA_SOURCE или что человек где-то пишет if в одну строчку а где-то такойже if в 4 строчки или кто-то внезапно решил написать свой парсер json-a, т.к. он творец, но допустил в нём ошибку, я думаю автор коммента больше говорил про такие штуки
Так я и не критиковал автора комментария. Но если писать 17 лет на C# и ни разу не сталкиваться с goto, то может просто круг решаемых задач не требовал знания такой вещи, как goto. Допустим я в своей практике занимался "творческими" задачами и приходилось пользоваться этим оператором. Возможно когда-нибудь моё творчество тоже кто-то раскритикует, назовёт код лапшой и перепишет все без goto, заодно уронит производительность какого-нибудь "творческого" алгоритма раз в 10. По поводу goto в dotnet можно ещё вот так посмотреть:
https://github.com/search?l=C%23&q=org%3Adotnet+goto&type=Code
но это уже совсем для смелых.
назовёт код лапшой и перепишет все без goto
Тут немного другой ход мыслей должен быть, чтобы решать проблему правильно:
goto это низкоуровневая операция
люди не умеют постоянно думать низкоуровневыми операциями
иногда бывает код, где абстракция, которая позволяет не пользоваться низкоуровневыми операциями, протекла и не работает (например, роняет производительность)
если мы воспользуемся низкоуровневой операцией руками, потому что знаем, что здесь она работает, лучше не станет, потому что сломаются типизация, кодтрансформеры, линтеры и коллеги
нужно починить абстракцию: ещё разок поискать какие-нибудь альтернативные фичи в ЯП, которые позволяют записать эти goto без просадки производительности (какие-нибудь там named break/continue, return, генераторы и т.п.), а когда совсем не останется вариантов, сделать кодогенератор, который генерирует код с goto.
Я посмотрел в один метод, в котором 10 goto. Которые вообще не нужны. Они все ведут на две метки в конце файла:
Done:
return retVal;
ReadFirstToken:
retVal = ReadFirstToken(first);
goto Done;
Почему вместо goto Done; нельзя написать return retVal; а вместо goto ReadFirstToken; return ReadFirstToken(first); для меня загадка.
Ага, и ещё парочку примеров правильного использования goto:
Done:
return ConsumeTokenResult.Success;
IncompleteNoRollback:
return ConsumeTokenResult.IncompleteNoRollBackNecessary;
IncompleteRollback:
return ConsumeTokenResult.NotEnoughDataRollBackState; return true;
IncompleteRollback:
return false;Несомненно, если переписать это творчество без goto, то оно потеряет 90% производительности
Вот этот код (первый попавшийся модуль в ядре) как ни переписывай без goto - всегда будет хуже, чем с goto.
Ну вообще для таких целей можно использовать менеджер контекста. Но увы, упираемся в возможности языка.
вы имеете ввиду аналог with из мира питона?
но там получается крайне многословная конструкция, и возникает вопрос: зачем она нужна? Только чтобы избежать goto?
Менее многословная чем вариант с goto, но с большим уровнем вложенности.
Да, коммент был исключительно про то, чтобы показать, что современные подходы достигли и превзошли уровень выразительности, который раньше можно было достичь через goto
А какая разница, если в байткоде все равно будет какой-нибудь JMP?
Так цель выпилить goto из кода, а не jmp из машинного кода. Когда у тебя есть менеджер контекста, ты его написал в одном месте и переиспользуешь во всех остальных местах. Сразу же избавляет то того, что кто то забыл вызвать завершающую функцию или перепутал их порядок. Плюс читаемость, плюс надежность. А то что компилятор потом его преобразует в тот же jmp, так это же хорошо, минимум накладных расходов значит.
Как минимум от 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;
}стал ли код лаконичнее? нет
стал ли он эффективнее? хз
а избавиться от goto можно
Он не стал менее лаконичным. Он вряд ли поменял эффективность (потому что переходы дословно те же). Зато все условные переходы, по которым можно прийти на err_clk видны из структуры кода (а не из его чтения).
Он не стал менее лаконичным
совершенно точно стал. теперь в коде больше строк, теперь длина этих самых строк тоже выросла
if (assertion_evaluating_to_true) {
error_handling();
goto cleanup_label;
}На широко известный в узких кругах макрос
require_action(assertion_evaluating_to_false, cleanup_label, error_handling());Код станет короче, понятнее, и «голого» goto для обработки ошибок там больше не останется, т.е. если goto там таки появится — он начнет намного яростнее бросаться в глаза, и все такие места можно будет найти грепом, и при этом не нужно будет отделять обработку ошибок от выходов из глубоких вложенных {} и т.п.
Хрен с ней, с длиной строк. Код стал менее читаемым. При каких условиях выполняется строка X? Надо добраться до начала блока, ага перед началом блока else, значит надо еще один блок промотать вверх до if. Но этот if вложен в другой else... Это какая-то "Игра в классики" Хулио Кортасара, а ведь изначальный листинг читался сверху вниз как линейный текст.
Вы, верно, шутите? RAII или defer.
Результат выполнения будет абсолютно одинаковым. Но я не могу взглянув на этот код с уверенностью в 100% сказать, что после замены goto на return даже в этих местах компилятор в итоге выдаст абсолютно одинаковый asm код. Чтобы ответить почему именно разработчики оставили в этих местах goto, нужно скомпилировать и смотреть в дизассемблер и делать бенчмарки. Я не думаю, что код, который парсит все Json в Asp.Net Core сервере писали глупые люди. У них 100% есть куча бенчмарков для этого кода, который запускался тысячи раз на разных архитектурах. Возможно есть причина в этих goto, и выигрыш даже 0.5% на ровном месте стоит чуть больше "красивого" кода. В противном случае, почему бы не открыть PR в кодовую базу dotnet и не предложить им улучшить читаемость кода и понимание control flow?
Потому что все эти ваши return ReadFirstToken займут больше места в байткоде (и в ассемблере, когда код откомпилируется), протянутся в кеш цпу, вытолкнут из него обрабатываемый текст, и просадят производительность. Конечно, я не проверял (и вообще на C# не пишу), но на других ЯП парсеры писал, и там компактность кода парсера (особенно если lookahead не ограничен и бывает большим) весьма важна.
Это видать писал адепт "одного return на функцию".
Слабонервным лучше не открывать, 60 операторов goto в 1-м файле.
У Дейкстры AFAIK претензия к использования GOTO только в качестве оператора безусловного перехода. В том же RISC-V вызов функций делается через инструкцию JAL, JARL (jump and link). Если у вас нет стека, то без goto вам никак.
goto не бывает безусловным. этот оператор всегда размещают в каких-то частях кода, при том что попадание туда ограничено массой условий.
конечно можно писать в самом начале функции `goto label`, но зачем?
Зависит от языка: на ассемблере сплошь и рядом. Например jump label в самом начале памяти ставится для перехода на entry point, так как перед ней как правило идет таблица векторов прерываний, а процессор стартует не с нулевого адреса. Также это будет использоваться если у вас жестко зашиты адреса, например для немаскируемых прерываний, а новый код туда просто не помещается. Тогда будете уходить по jump и возвращаться. И как я уже сказал выше, Вы исходите из того что в системе есть стек куда сохраняются адреса возвратов функций. Уберите из системы стек и останется только goto. Но конечно можно сказать ассемблер - не ЯП.
Три раза ха. Олдовый ассемблерный goto - это восхитительная в своей хтони вещь, которая позволяла вам, к примеру, телепортироваться из середины одного метода в середину другого, позволяя им шарить куски кода без вынесения их в независимые подпрограммы.
Бывает. Например, при имплементации far jump линковщик раньше мог сделать goto на другой goto :)
И исключения в шарпе тоже есть. И всем этим можно пользоваться, никто в шарпе не заявляет, что это антипаттерны.
Автор перегибает =)
Прям антипаттерн не заявляют, говорят exceptions are expensive
Ага, меня это в какой-то момент настолько выбесило, что я в итоге написал свой велосипед для работы с сокетами.
Если кратко, то при неблокирующих операциях с сокетами постоянно бросаются исключения (EWOULDBLOCK, EINPROGRESS и т.д.), которые на самом деле не ошибки, а просто штатная работа API. Из-за этого при подключённом отладчике в debug-сборке производительность падала до пары десятков IOPS. Без отладчика было чуть лучше, но все равно критично.
P.S. Возможно, сейчас дела с этим немного лучше, но тогда это были времена Mono, когда .NET Core только появлялся.
у нас один разработчик как-то начитался о вреде "goto" и стал вместо "goto" писать "throw SUCCESS", в продукте все исключения логируются, мы долго потом думали, что означают в логе записи: Exception: operation completed successfully.
Уж лучше бы он писал "goto"
Разбираться в творчестве творцов - шедевр )
Сразу лайк и подписка, видно родственную душу 🙃
Мне кажется, это частый случай, когда исключение воспринимается как правило.
Правило в том, что с goto обычно все плохо. Но... иногда в рубрике "программисты шутят" появляется какая-то интересная задача, которая с goto решается изящнее, чем-то лучше. Такое бывает, верю. Но надо понимать, что это исключение.
Или вот термины "военная хитрость" и "боевой дух" (то, чему меня последний год чтения новостей научил) - конечно же лучше, когда есть высокий боевой дух. Но как мы видим, не слишком он помогает. Похоже, ракеты-пулеметы тоже имеют некоторое значение, а боевой дух - скорее дополнение, хорошее, полезное, но не такой значимое, как показано в детских книжках и фильмах.
Или, помню множество историй о том, какой "дутый" ВВП в развитых странах: мол, можно один и тот же товар пятьсот раз перепродать, ВВП по цифрам будет большой, а по факту никакой. И да, это тоже верно, так же, как полезность goto в редкой задачке. Полезное исключение, которое хорошо бы знать, понимать, и не забывать, что оно - именно исключение.
Вообще, мне кажется, правила важны только в детстве, когда ты их еще не знаешь. А в более взрослом возрасте правил знаешь даже больше, чем нужно и гораздо важнее понимать, как эти правила "пересекаются", какое правило важнее другого, где границы применимости каждого правила.
Оператор goto - для меньшевиков. Настоящие марксисты используют только setjmp/longjmp. Только такой функционал позволяет по-настоящему вырваться из контекста.
то Вы ругаете тех, кто хейтит goto, то сами безапелляционно ругаете микросервисы. Нет ничего плохого ни в том, ни в другом. Каждой задаче- свой инструмент, плоха крайность.
goto - технологический инструмент
микросервисы - инструмент организации труда (ну или отчуждения, если по Марксу)
это разные сферы, одна - IT'шная, другая - вне-IT'шная.
как-то так
ну или отчуждения, если по Марксу
При чём тут отчуждение труда вообще? В монолите человек также пишет свой модуль и не может написать свою систему один и с нуля.
IT не существует вне бизнеса, какое бы технически классное решение ты не предложил, если затраты будут выше возможного, бизнес загнётся и решение будет никому не нужным. Оно останется классным, но мертвым.
Именно потому микросервисы - наше будущее 🤷♂️
Автор решил много набросить на вентилятор
1. Goto - причины не в авторитете, разработчики согласны с доводами, они очевидны, проверены и логичны. Поэтому требование по неиспользованию возведено в абсолют, неудобства его отсутствия ничтожны на фоне преимуществ когда программисты никогда им не пользуются. Вопрос к автору - что вам не понятно в этих доводах и причинах "табу" на goto? Вы писали сколько-нибудь сложные проекты где он используется как значимый способ управления потоком вычислений, а не в 1 месте?
2. Про динамическую типизацию - аналогично причины почему разработчикам не нравится опять же известны, широко обсуждались, крупные коллективы разработчиков осознали проблемы и всячески стремятся типизировать проекты. Проблемы на этапе написания кода - подсветки синтаксиса, валидации и автодополнения кода. Проблемы на этапе исполнения - ошибки типов в рантайме, накладные расходы на динамическую типизацию. Вопрос к автору - вы разрабатывали сколько-нибудь крупные и\или нагруженные проекты с динамической типизацией? Вам непонятны аргументы или у вас есть чем их ультимативно перебить?
Вы писали сколько-нибудь сложные проекты где он используется как значимый способ управления потоком вычислений, а не в 1 месте?
я писал модули для ядра Linux. однако я в дисклаймере написал, что спорить по частностям не буду. Загляните в исходники ядра и убедитесь, что код с зависимой инициализацией без goto будет значительно менее читабелен
Именно по этому есть оговорка про значимость - то что приведете 1 пример из проекта на несколько миллионов строк кода Linux. Запрет GOTO возник когда в языках было принято строить на нем почти все управление выполнением кода. Это сейчас языки и подходы развились и приспособились (ввиду запрета на GOTO) - появилось множество удобных и понятных замен GOTO, изменились подходы к структурированию кода
Про динамическую типизацию
Не уверен на 100%, но мне кажется что довольно много людей не понимает того, что если писать средне-крупный проект, то для проверки работы сервиса/программы придется писать либо много хороших тестов, которые будут проверять работу и то, что типы переменных можно безопасно использовать, либо долгую отладку приложения.
кстати очень часто (см. обсуждения на хабре) аппологеты типов именно противопоставляют их тестам.
Тестировать нужно в любом случае, просто если язык типизированный то обычно это значит только то, что будет значительно меньше проблем с типами. А например для тесты для проверки работы парсера url, придется писать в любом случае независимо от того на каком языке он был написан.
просто если язык типизированный то обычно это значит только то, что будет значительно меньше проблем с типами
а проблемы с типами не составляют и 1% всех возникающих на стадии тестирования проблем. вот я о чём
NullPointerException - это в некотором смысле тоже "проблема с типами", например (точнее, с тем фактом, что nullability никак в этих типах не выражена). Их тоже "менее 1%"?
а проблемы с типами не составляют и 1%
Может я мало пишу на таких языках, но довольно часто встречаюсь с такой проблемой, и они составляют явно не 1%. Думаю многие просто не обращают внимания на эту проблему, т.к. часто ошибку можно увидеть довольно быстро. Особенно неприятно она тогда когда случайно можешь присвоить новые данные уже существующей переменной, которая например раньше была объектом, а стала примитивом или наооборот.
проблемы с типами это когда вместо килограмм случайно в формулу прислал километры.
такое да, иногда бывает, но это от явного непонимания "а что же такое я делаю". И такое очень легко выявляется тестами, поскольку является грубой ошибкой.
А вот система типов гарантирует отсутствие ошибок типов. Т.е. не 99.99%, а ровно 100%. С этой стороны — точно не прилетит. Это многого стоит!
А вот система типов гарантирует отсутствие ошибок типов.
ничего она не гарантирует. возьмём пример на GO приведённый в статье и предположим, что foo и bar возвращают РАЗНЫЕ типы ошибок.
что сделает программист в первую очередь?
приведёт к одному типу, аггрегирующему обе ошибки (enum, struct не важно). А с этого момента ваша система типов перестаёт что-либо гарантировать.
и ещё раз повторюсь: ошибки вида "вместо километров прислали килограммы" - крайне редкие, возникают только от тотального непонимания "а что же такое я делаю?"
Если он осознанно скастует разные типы ошибок к агрегирующему типу ошибок - он берёт на себя отвественность за это. Но при этом он будет точно знать, что ему прилетит на вход агрегации ошибок точно типизированная ошибка, а не строка "ой больно мне больно".
foo и bar возвращают РАЗНЫЕ типы ошибок.
Есть стандартный тип error, которым используется в 99% случаев, и поэтому никто не кастует ошибки в обычных проектах(хз зачем это вообще делать в го).
"вместо километров прислали килограммы"
В большинстве случаев, это обычная невнимательность, но это по моему опыту, возможно у вас всё по другому.
Есть стандартный тип error, которым используется в 99% случаев, и
поэтому никто не кастует ошибки в обычных проектах(хз зачем это вообще
делать в го).
(просто Rust под рукой и свежее в голове, потому пример не Go, а Rust)
Вот например берём библиотеку yaml-rust - она возвращает свои ошибки, а std:: - свои. И это логично: раз язык типизированный, то возвращая более одной ошибки нужно разделять их по типам (иначе машинно обработать их будет сложно).
Ну и соответственно, поскольку разработчики НЕИЗБЕЖНО сталкиваются с проблемой машинообрабатывания ошибок, то они вынуждены вводить новые их типы.
А другие разработчики, которые пишут код которому "не важно какая ошибка, если она есть - передать её вверх по стеку" (99.9% кода) - мучаются с объединением всех встреченных типов.
При том, что этим мог бы заниматься компилятор
А для этого есть наследование и, если очень надо, рефлексия. Error есть Error.
А другие разработчики, которые пишут код которому «не важно какая ошибка, если она есть — передать её вверх по стеку»
А вот это да — меня тоже коробит. Только начал экпериментировать с Rust'ом — там наверняка же есть методики вроде ленивой цепочки или что-то в этом роде, которая позволяет это делать автоматически. Есть же?
есть - знак вопроса.
`foo = bar()?`
эквивалентно - ошибку передать по стеку выше, ну а если её нет - присвоить foo.
Но для этого и нужно соединить все ошибки в один тип
Нет, соединять все ошибки в один тип не нужно, если это не ошибки из вашего кода, конечно, например:
fn return_result(res: Result<(), YamlError>) -> Result<(), MyError> {
res.map_err(|source| MyError::IO { source })
}А другие разработчики, которые пишут код которому "не важно какая ошибка, если она есть - передать её вверх по стеку" (99.9% кода) - мучаются с объединением всех встреченных типов.
Или берут что-нибудь типа thiserror, пишут простенький тип, вешают аннотацию и возвращаются к бизнес-логике, потому что компилятор при помощи этих аннотаций может заниматься много чем.
Или берут что-нибудь типа ..., пишут простенький тип, вешают аннотацию и возвращаются
а могли бы вместо этой сибурды заниматься полезным делом, например лишний тесткейз описать
https://habr.com/ru/post/560370/ — развёрнутый ответ.
достаточно строгая система типов гарантирует отсутствие данного класса ошибок
тут ошибка
не гарантирует
гарантирует бОльше телодвижений, требуемых к совершению программистом, соответственно чуть меньше ошибок такого класса.
Однако открытый вопрос: а стоит ли овчинка выделки?
Очевидный ответ - не стоит
В чём ошибка?
в том, что НЕ гарантирует.
Гарантирует = это про 100%.
найдя один контрпример мы делаем высказывание невалидным. У вас оно невалидно. (пример выше приведён)
Ещё раз, тезис: достаточно мощная система типов гарантирует отсутствие ошибок
нет
Стоит. Я предпочту
Не стоит. Я не предпочту.
На этапе поддержки и крупного рефакторинга они и половину составлять могут.
Вы предлагаете покрывать тестами всю возможную вариативность типов которые могу прилететь на вход?
Вы предлагаете покрывать тестами всю возможную вариативность типов которые могу прилететь на вход?
Нет, я этого не предлагаю. Для иллюстрации того, что я говорю приведу пример, недавно на питоне я писал парсер и я использовал библиотеку для работы с url. В нескольких местах я ошибся и в функцию передавал не строку а объект этой библиотеки, самое плохое, что этот скрипт отрабатывал, а ошибка была найдена не сразу, например в c++ или go я бы физически не смог допустить такую ошибку, т.к. у меня проект не скомпилировался бы из-за того, что я использую объект вместо строки, а это был маленький скрипт на 300 строк, если будет проект на 5-10к то вероятность допустить ошибку будет гораздо выше. Поэтому для ряда функционала придется писать больше тестов или проверок в коде, ну или пойти путем дебага.
на питоне я писал парсер и я использовал библиотеку для работы с url. В нескольких местах я ошибся и в функцию передавал не строку а объект этой библиотеки,
Type hints + PyCharm + mypy (в strict mode) очень сильно уменьшают вероятность таких ошибок.
Зачастую это так. Как минимум, потому что тебе не нужен тест на то, что "результат вот этой функции -- действительно число". Тебе это прямо в сигнатуре функции дано.
Соответственно, остаётся проверять исключительно логику кода, а не его типы.
В плане отношения к тестам - такого ввиду не имел. А вот невозможность IDE понимать тип, подсветить ошибку в имени метода (например) это прям боль - и понижает производительность моего труда. Накладные расходы на динамическую типизацию глобально неприятные. Поэтому динамические языки хороши для небольших продуктов и маленьких команд, для средних и крупных они вызывают проблемы.
В плане отношения к тестам - такого ввиду не имел. А вот невозможность
IDE понимать тип, подсветить ошибку в имени метода (например) это прям
боль - и понижает производительность моего труда.
то есть вы подтверждаете тезис статьи, что мода на типизированные языки именно от того и растёт, что для них проще писать линтеры.
Для них проще писать полезные программисту линтеры. То бишь, те, которые помогают ему, а не загоняют в рамки. Если таких не существует - ну, сочувствую.
Проблема не в простоте написания линтеров - их написали уже умные дядьки. Проблема в том что в динамических языках чисто алгоритмически тип на месте может быть невыводим - насколько я знаю это сводится к проблеме останова. И второе - это цена выведения типа в динамических языках, тип по месту приходится вычислять с высоким потреблением памяти и процессора (и это фундаментальная не решаемая в общем случае насколько мне известно проблема), отсюда постоянно тормозящие IDE которые еще и тип не всегда выводят в конечном итоге.
А знаете почему JSON захватили мир? Это данные с нестрогой типизацией
Ну да, только в rfc написано немного другое, где объект это name состоящее из строки и value, которое удовлетворяет одному из типов.
Это никак не отменяет того факта, что всё многообразие JSON-значений можно описать одним типом.
По сути все нестандартные типы в json переводятся в строку, отличие от питона ил js в том, что там когда видишь переменную, то ты не можешь быть уверен в типе, т.к. там объекты представляют собой именно отдельный объект, а не строку, в JSON когда смотришь на него, то всегда можно определить тип любого элемента, поэтому его не назовешь динамическим.
Если бы JSON поддерживал стандартизованную схему в том же виде как xml то он бы стал значительно лучше и при этом это бы никому не мешало
Забавно, что на ассемблере чуть ли не самой используемой командой является JMP (и её разновидности), которая, по сути, и есть GoTo...
Поэтому требование по неиспользованию возведено в абсолют,
Ага. Вплоть до того, что есть ортодоксы, которые отрицают не только выход из вложенных циклов, но и исключения и return из середины функции, ведь всё это ломает control flow.
Боритесь! Отказывайтесь от вакансий, где вам предлагают работать над микросервисами.
Есть предложение еще и от денег отказываться. Желтый дьявол, презренный металл и далее по тексту. Брать продукцией! А при коммунизме все равно все бесплатно будет.
такое предложение будет неконструктивным (по крайней мере на данном этапе развития общества).
На деньги сейчас завязаны основные жизнеобеспечивающие функции.
а то что вы предлагаете сродни следующему: "Если goto иногда полезен, то давайте применять goto абсолютно в каждой строке. Получится фигня, сами можете убедиться".
Но нет, истинный пролетарий на подобную уловку не поддастся!
Вам нужно профсоюз организовать. И провести стачку "против микросервисов" - все технологии уже сто лет назад апробированы.
А если серьёзно, то нужно ребрендинг сделать монолитам и внедрять как новинку.
Вам нужно профсоюз организовать
профсоюзы - буржуазный метод перенаправления революционной энергии пролетариата... в свисток.
об этом ещё товарищ Ленин писал.
Эх, всегда так в России. Только революция и никаких переговоров.
Я, кстати, сильно удивился, что среди кучи аргументов Ваш "босс" ни разу не проговорился о правде в этой шутке. Чем больше микросервисов, тем больше нужно разработчиков, тем круче их начальник. Вот это правда как она есть. Как "босс" говорю.
Эх, всегда так в России
а почему "Эх"?
Это не хорошо и не плохо, это просто менталитет у нас такой. У немцев, например, другой, у французов -- третий.
Просто модель поведения, выбранная нашими предками.
Россия тут ни при чем. Это везде так.
А если серьёзно, то нужно ребрендинг сделать монолитам и внедрять как новинку.
Это гениально по-моему. На уровне SSR веб-приложений. Предлагаю IMC (In-Memory Communication) микросервисы.
Есть интересная тема - JAMstack (Javascript/API/Markup). Это "новые статическе сайты". Они прекрасны - их можно хостить на CDN, быстро загружаются, их любит гугл, они приятны пользователям (не тупят) и за счет JavaScript они абсолютно функциональны. Ну и достаточно сложно взломать сайт из набора HTMLок (в отличие от такого же сайта-визитки на вордпрессе).
Но эта технология (в каком-то смысле возврат к ~90-ым годам) сейчас модная потому, что второй раз заходят в уже другую реку. Сейчас есть очень мощный JavaScript и поэтому сайт может быть "живым". В 90-ые, если у тебя сайт бы не на PHP/Perl - он был "мертвым".
Вот если бы была какая-то технология, которая ты как-то делала монолиты не такими как раньше - это было бы интересно.
Что такое микросервис, значительная часть которого кодогенерируется? Это способ изолировать разработчика от целого (и друг от друга). Это
жёсткий контракт в 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-ы между своими микросервисами
Основная идея в том, что нужно стараться осознанно обрабатывать ошибки
и потому возьмём кнут и заставим разработчиков стараться. Иных мер убеждения нет.
Просто бизнес, ничего личного
и потому возьмём кнут и заставим разработчиков стараться.Иных мер убеждения нет.
Ну для большинства го - это не первый язык, никто не заставлял их учить его и писать на нём. Очень много людей переходят на него после плюсов и довольны этим языком(это личный опыт и знакомства, поэтому как у других я не знаю). Да и в целом никто не заставляет писать обработку ошибок просто в реальности на написание этой логики тратится мб процентов 10-15 времени, но за счет этого почти всегда получаешь точное место ошибки и хотя бы примерное описание того и что произошло.
К сожалению, видел довольно много кода, где либо люди забивают на обработку ошибок, либо заворачивают большой кусок кода в try и пишут один catch(...) который обрабатывает все ошибки и пишет сообщение по типу "произошла ошибка". Не знаю насколько это законно в продакшен коде.
В могу сказать, что го подходит не всем у языка есть свои + и -, своя идеология и свой стиль написания кода, мне тоже не нравится ряд языков, но это нормально, если язык занимает свою нишу значит имеет определенные достоинства, за которые его выбирают.
Ну для большинства го - это не первый язык, никто не заставлял их учить его и писать на нём
рыночные меры убеждения заставляли.
- Хочешь работать в транснациональной корпорации?
- да
- учи Go
либо заворачивают большой кусок кода в try и пишут один catch(...)
который обрабатывает все ошибки и пишет сообщение по типу "произошла
ошибка". Не знаю насколько это законно в продакшен коде.
по мне так это - идеальный паттерн
стек ошибки отправляется в хранилище, откуда разработчик может достать, разобраться и поправить.
вы не видели на сайтах: "случилось что-то непредвиденное, мы уже разбираемся"? это вот оно и есть
"случилось что-то непредвиденное, мы уже разбираемся"
Для фронтэнда да идеально, пользователю не нужно знать что именно произошло, а условну разрабу разгребать стектрейс, а не конкретную ошибку не очень понравится.
Хочешь работать в транснациональной корпорации?
Помимо го нужно еще выучить язык, решить много задач на leetcode, получить визу, подготовиться к собеседованию, да и есть куча вакансий где пишут на питоне, ноде, яве, го не настолько популярен как вы представляете это в комментарии, да и в жизни бывает такое, что приходится делать что не нравится
и потому возьмём кнут и заставим разработчиков стараться.
То есть мы по умолчанию считаем разработчика ленивым и халатным?
Приходишь потом за такими вот творцами и понимаешь, проще все сравнять с землёй , чем реанимировать. Макароны плотно оплетающие велосипеды. И главное эту люди потом гордятся, я один все наваял, а после моего ухода целый отдел набрали. И не вдомек им, что необходимость в целом отделе, это последствие их творческих порывов. Бегут они по жизни дальше несомые творческим шилом в пятой точке оставляя за собой макаронные джунгли, а кому то потом все это разгребать и поддерживать.
есть анекдот про переписывание кода. он матерный потому приводить здесь не буду
краткое содержание: заказчик жалуется, что каждый новый нанимаемый им программист называет предшественников нецензурно и начинает переписывать.
вместо сравнивания с землёй может лучше попытаться разобраться? Не?
В вашем утверждении логическая ошибка, если творец низкоквалифицирован, то как получилось что на его замену нужна целая команда проффесионалов? Может наоборот, вместо одного спеца набрали кучу студентов которые каждый в своей стезе что то понимает и этот змей горыныч кое как тянет то что раньше делал один человек? Или просто бизнес вырос из решения которое предлагал один человек и настала пора масштабироваться.
P.S. Чем квалифицированнее разрабочик тем он сдержанее относительно оценки труда предшественников и тем реже от него можно услышать предложение "а давайте все перепишем на {itemname}". Ничего личного, просто собственный опыт и наблюдения.
то как получилось что на его замену нужна целая команда проффесионалов?
А тут может быть разница между решением работающим как-нибудь и решением, работающим хорошо , стабильно и в рамках строгих метрик.
Нет в моем утверждении логической ошибки.
Человек лепит свою нетленку. Сначала он выкатывает "фичи" достаточно бодро, становится часть коллектива, герой на коне, помог всем и вообще "сын маминой подруги". Потом фичи появляются все реже, но люди привыкают, он же герой. Потом система начинает терять стабильность и наш герой героически ее чинит, и в выходные, и ночью, и в отпуске , бухгалтерия в отчётный период носит его на руках он опять всех спас, а про новые фичи все давно забыли, в этот момент герой уже неотделимая часть механизма.
И в какой-то момент герой расправляет плечи и летит лепить новую нетленку. И вот тут и выясняется, что не зря он по ночам работал, а новые люди о чудо не хотят этого делать, разгребать чужие косяки ценой своего сна, и действительно сложно поместить в голову то нагромождение костылей которые были заботливо везде расставлены, и кнопочку два года в красный он не просто так не мог перекрасить, а потому, что проект валиться совсем при таком изменении в самых неожиданных местах.
И да, я не призываю ничего переписывать с нуля. Просто нужно понимать, что рефакторить нетленку, дороже и дольше чем написать с нуля, но чаще всего применяется именно глубоки рефакторинг, поскольку остановить бизнес на пару лет это не очень вариант, да и результат не гарантирован.
Вы знаете вот опять таки субьективно и из личного опыта, команды никак не защищены от подобного..Я лично рефакторил/переписывал проект целыми модулями за командой лепил, больше года..привел в состояние "оно работает и не падает от ветра" и я вам так скажу, парни работали по правилам и бест практикс, настолько что мне это слово уже приелось. Потом правда бест практикс оказались макоронным кодом который писали 2 года до меня.
Так что я не знаю какого именно сферического коня в вакууме вы тут описываете, но помоему важно не количество разработчиков, а качество. Потому что "псих одиночка" которого вы тут описали может быть действительно результативным. Я знаю потому что в моей работе такой был, правда он ничего не спасал, у него все было вылизано за большое количество лет и работало как надо. Мой ему низкий поклон, очень умный дядька, занимался разработкой архитектур процессоров в 90-х.
Вы не против подискутировать по сути, но по какому тезису? Который вынесен в заголовок? Или по тезису типа: "в it происходит "первая промышленная революция"?
Вы не против подискутировать по сути, но по какому тезису? Который вынесен в заголовок?
именно
Или по тезису типа: "в it происходит "первая промышленная революция"?
промышленной революции в IT не происходит. IT не развивается (интенсивно) уже более полусотни лет (в списке литературы есть статья на эту тему, кстати)
Жаль, что ни разу к микросервисам не прикасался.
А вот про отсутствие развития в it согласиться не могу. И статья в источниках никак тезис об отсутствии развития не подтверждает. Здесь и всегда, конечно же, ИМХО.
Еще забавно, что прочитав вашу статью, я резюмировал ее в тезис про революцию, с которым вы не согласны))
А вот про отсутствие развития в it согласиться не могу
в комментарии было слово "интенсивно"
простое заполнение пустого пространства - не есть интенсивное развитие.
в школе учили:
если крестьянин засеивает всё больше и больше новых полей - это экстенсив (то что есть в IT)
если он увеличивает урожайность (разрабатывая новые способы итп) - это интенсив
что есть в IT?
новые технологии? какие? асинхронность? была 50 лет назад, сейчас её просто стало больше
может быть нейронные сети? и им тоже более 50 лет. просто люди вручную насобирали базы данных и стало возможным эту информацию через нейронки пропускать. Не более того. ничего нового в них не. чистое экстенсивное развитие.
может новая парадигма появилась? аналогичная ООП? снова нет. и даже типажи на это не тянут.
Асинхронность и прочие базовые вещи (в том числе и парадигмы) - это как алгебра в современной математике. Простая основа, кирпич из которого можно строить замки. Я не могу принять этот довод как показатель отсутствия интенсивного развития. Для меня это не очевидно. Сможете ли вы привести аргументы в пользу того, почему базовые концепции должны быть заменены при интенсивном развитии? Например, почему в будущем мы должны отказаться от асинхронного программирования или от использования классов?
То, что нейронные сети были изобретены 50-70 лет назад - не показатель того, что с тех пор не было интенсивного развития. Посмотрите на количество публикаций по темам, связанным с ИИ и с нейронными сетями. Последние годы виден невероятный рост отрасли и проникновение технологий, связанных с AI, во все сферы жизни и промышленности. Как ни крути, но такой рост (скорее экстенсивный) приводит к качественному изменению этой технологии, то есть к росту интенсивному. Если раньше (20 лет назад), нейронные сети могли распознать рукописную букву, то сейчас вы можете попросить ее переписать текст, поуправлять авто или технологическими процессами, придумать вам историю или анекдот, поговорить с ней, написать картину, да даже код за вас написать, то есть формально нейронные сети могут самовоспроизводиться (не принимайте этот аргумент как совершенно истинный, он возможный))) и т.д. и т.п. Это качественное изменение, то есть интенсивный рост отрасли. Я не понимаю, почему такой рост в статье по ссылке называют экстенсивным. Экстенсивно - это когда ты преумножаешь существующее, а когда тебе приходится изобретать новые технологии, чтобы обуздать возрастающие объемы, - это и есть интенсивное развитие.
Если переходить к более привычному программированию, то резюмируя вашу статью, я, как человек не знающий что такое микросервисы, понял их как элемент интенсивного развития, как новую технологию, направленную на то, чтобы создавать огромные программные системы, которые могут обслуживаться тысячами неуникальных работников, дописываться, изменяться, развиваться на лету, которые не могут существовать в рамках тех технологий, которые были 20 лет назад. Раскрывая тезис: экстенсивный рост сложности программ привел к появлению этой технологии (качественному росту, интенсивному развитию всей отрасли), чтобы экстенсивное развитие могло происходить дальше.
Переходя к аналогиям с крестьянами: в какой-то момент вспахать одной лошадью землю уже не получится, придется изобретать трактора, переходить к разным сортам злаков, имеющих разбег во времени посева, придумывать способы хранения, транспортировки и обработки зерна в больших объемах. Раньше для всего хватало одного крестьянина с лошадью (программист и Pascal), а теперь нужно городить огромные системы (бэк, фронт, DA, DS, DE, DevOps, и т.д. и т.п.), и в разных частях систем будут разные технологии (пусть и построенные с использованием базовых примитивов). И именно в этом есть интенсивное развитие.
Асинхронность и прочие базовые вещи (в том числе и парадигмы) - это как
алгебра в современной математике. Простая основа, кирпич из которого
можно строить замки. Я не могу принять этот довод как показатель
отсутствия интенсивного развития.
Интенсивность развития предполагает на замену кирпичных зданий принести железобетон.
а массовое кирпичное строительство - это просто заполнение ниши - чистой формы экстенсив
Речь не о строительстве все-таки, а о том, что есть базовые концепции на которых все строится. Почему для вас интенсивное развитие невозможно без их замены?
Речь не о строительстве все-таки
я пытаюсь аналогиями донести различие "экстенсивное развитие" vs "интенсивное"
PS: Помимо прочего, есть такое понятие (марксистское кстати), как "Переход количества в новое качество".
Да, если экстенсива будет много-много-много, то это даст новое качество (или не даст), о котором можно будет подискутировать: это интенсив или экстенсив.
Да, повсеместное применение нейронок неизбежно приводит нас к новому качеству. Тут я бы и спорить не стал. Другой вопрос, что нейронкам полвека и за эти пол века в них ну почти ничего не поменялось (это чистый экстенсив)
Давайте про нейронки в другую ветку ниже, а здесь только про базовые концепции.
Аналогии лишь для красоты и уточнения)) Если я правильно понял, то для вас один из признаков отсутствия интенсивного развития - это, например, повсеместное применение асинхронного программирования. Почему?
Если я правильно понял, то для вас один из признаков отсутствия
интенсивного развития - это, например, повсеместное применение
асинхронного программирования. Почему?
если снова принести аналогию с крестьянами (они правда для красоты и уточнения)
Так вот, жил-был крестьянин и было у него три поля.
На одном он всегда сажал пшеницу, на втором - картошку, на третьем - помидоры.
Однажды сосед ему и говорит: чудак человек, чередуй ежегодно что где растёт и твоя урожайность повысится.
Но крестьянину было пофиг. Он не хотел развивать свой хозяйство интенсивно.
Затем прошло время и бОльшие урожаи всё-таки ему потребовались: ценники на рынке упали, барщину подняли и он таки перешёл к новому виду хозяйствования.
Является ли этот шаг интенсивным развитием? С одной стороны вроде бы да. Но запаздывая за другими на полвека, кажется, что уже и нет.
вот какое-то такое у меня отношение к асинхронному программингу.
То, что нейронные сети были изобретены 50-70 лет назад - не показатель
того, что с тех пор не было интенсивного развития. Посмотрите на
количество публикаций по темам, связанным с ИИ и с нейронными сетями.
Последние годы виден невероятный рост отрасли и проникновение
технологий, связанных с AI, во все сферы жизни и промышленности.
50-70 лет назад чего не хватало для проникновения этих технологий во все сферы жизни? Двух вещей:
вычислительной мощности (это не про IT, по крайней мере не про софтверное IT)
количества материала для обучения. то есть вручную составленных 100500 баз данных измерений.
то есть если говорить, что нейронки - это революция (интенсив) то произошла она 50+ лет назад, а теперь мы пожинаем её плоды.
как-то так.
Давайте посмотрим на этот вопрос по другому. Перцептрон Розеблата (речь про него, как я понимаю) - это просто функция от линейной композиции нескольких переменных. С этим работал еще Ньютон (но что-то мне подсказывает, что началось все задолго до него). Получается нейронные сети были изобретены несколько веков назад? Из эти века мы всего лишь научились использовать много функций, благодаря которым можем работать с большим количеством информации, то есть это было простое экстенсивное развитие? А ChatGPT - просто огромная функция (экстенсивно развитая), а не нечто большее?
Ну и слегка подкину на вентилятор: а что такое человек? Экстенсивно развитый многоклеточный организм с существенным увеличением количества клеток? Или в какой-то момент произошел интенсивный процесс развития, хоть состав клеток особо то и не изменился?
Ну нет, это слишком сильное упрощение, так можно сказать что нейросети не развивались тысячи лет, ведь сложение, умножение, вычитание и деление существуют давно.
Буду ссылаться на метафору строительства
Я бы сказал что в нейросетях с персептрона Розенблатта было как минимум несколько действительно революционных шагов, за уши их можно назвать эволюционными, но все-таки я считаю их именно революционными:
1. 80-90ые, сверточные слои для обработки изображений, рекуррентные слои для обработки текста и последовательностей. Это именно смена кирпича на железобетон, то есть мы меняем строительный материал с полносвязного слоя на слой сверточный или рекуррентный. Если свертка существует давно как оператор обработки сигналов, то здесь она все-таки используется по-другому. Необходимо было разработать неплохой мат аппарат для этого, а еще и поверить что это вообще рабочая история. Там несколько раз нагло закрыли глаза на ограничения математики и перешли скорее к практическим приближенным вычислениям в ущерб тому, что математически не очень работает. Пример - функция активации ReLU (=0 if x <= 0 and =x if x>0), которая не дифференцируема в 0, но все работает. Тут важный момент становления "науки нейросетей", если раньше было "придумаем аналитически математикой, потом будем обучать", то сейчас "сделаем что-то, что хорошо работает, потом математикой попробуем объяснить как это работает". Это не конкретно про ReLU, просто остальное сильно сложнее для примера, но таких "хаков" сейчас уже десятки-сотни.
2. 2010ые, глубокие сети, лидерство нейросетей в распознавании изображений. Кажется, что это чистой воды эволюция, но нет, некоторые время глубокие сети не считались чем-то адекватным из-за 1) проблем обучения 2) теоретически три полносвязных слоя могут выучить вообще все (это, емнип, даже математически доказано). Поэтому объединить много слоев и заставить это работать -- именно что революция (ей и стало по духу). Это как начать строить многоэтажные дома из тех же материалов, тут нужен особый подход и технологии.
3. Наше время -- огромные сети на архитектуре трансформеров, которая тоже вполне себе революционная, общего у трансформера и исходного персептрона, как у шалаша и небоскреба, тоже дом, но есть нюанс. Уже и материалы и технологии строительства другие.
20-30 лет назад были уже все виды сетей, но не было: доступных БД с данными для обучения, и навреное главное - не было достаточных вычислительных мощностей. В середине 90х будучи еще школьником старших классов увлекся этой темой, когда про нее особо и не слышали. Обучать слабенький персептрон на 486й машине можно было только из большой любви к науке, практической пользы не проглядывалось.
А вот что конечно явно изменилось, так это подход к обучению НС, как залог успешности результата, вот тут можно зачесть прорыв.
20-30 лет назад были уже все виды сетей, но не было ...
А ещё не были разработаны эффективные алгоритмы для оптимизации коэффициентов нейросетей. Алгоритм Adam — это 2014 год. До него все использовали SGD (и хорошо, если с моментами), с которым и с нынешними мощностями мало чего можно добиться.
Также не было понимания, что решают именно глубокие (многослойные) нейросети. Многим эта идея казалась бесперспективной, из-за чего не удавалось достичь с помощью нейросетей результатов приемлемого качества.
монады - такая же колбечная лапша, просто вид сбоку.
мало того, взяли очевидное, доступное во многих языках, и назвали модным (монадным) словом...
мда
Какая колбечная лапша? Где вы увидели коллбеки в List/Maybe/State/etc?
колбечный (иногда асинхронный) код можно оптимизировать по разному. Промисы, монады итп. Потом кто-то неизбежно приходит и говорит "ну что за гадость?" и схлопывает это в файберы/корутины, позволяющие писать нормально, без колбеков.
берём объект каждый метод которого возвращает self и пишем
foo
.bar()
.baz()
чем не монада? ах возвращаемое значение нужно? ну дык добавьте его. это что, прорыв? да ну нафиг
дык и я вам постоянно это же говорю.
смиритесь, но вы - балабол
что такое функциональное программирование?
это программирование, при котором разработчик описывает что происходит (функции), а не манипуляции с данными.
в общем виде функциональный код:
foo(bar(baz(data0)))
императивно этот же код можно переписать
let r = baz(data0)
let r = bar(r)
и так далее
вот эти bar, baz - колбеки/функции/хоть пирожком назови.
монады - это способ попытаться остаться в парадигме функционального программирования, но так, чтобы было похоже на императивное.
таких способов много: промисы, всегда возвращаемый self во всех методах, монады, и прочие map-reduce.
Только речь идёт о том, что раз вам так хочется писать псевдоимперативно, то пишите императивно! Это будет эффективнее.
Нет? не мучайте функциональный язык
Как я и писал, у вас полное непонимание
как я и писал выше, у вас полное непонимание.
неспособность за частностью увидеть целое. Упёрлись в свой идрис и приводите совершенно никчёмные примеры, совершенно не в тему.
ну хорошо хоть идрис выучить удалось, осталось научиться писать на нём полезный код.
понимаю, задача не про вас, но попробуйте поставить такую цель
на ваши - нет
притчу о вопросах, на которые не могут ответить 100 мудрецов помните?
как раз ваш случай
Ваш тезис: монады — колбечная лапша.
нет, видите, вы даже прочитать не можете внятно
монады - такая же колбечная лапша, вид сбоку
монады - просто одно из средств борьбы с колбечным адом: промисы, мап-редюсы, конвееры из точек, монады - всё одного поля ягоды.
Впрочем я обещал с вами не спорить, поэтому это мой последний коммент к вам.
А к оппоненту, как где-то выше упомянули имеете личную неприязнь, поэтому не сдерживатесь и пытаетесь спорить, выставляя себя местами не в лучшем свете.
Все это плохо влияет на восприятие статьи, так как сильно подрывает образ «матерого деда, который комитил в ядро еще когда не все читатели свой первый hello world написали''.
Поскольку вы в целом воспринимаете оппонента очень предвзято, и также относитесь к его аргументации (а в данном случае опровергать чужой тезис пришли именно вы), я попытаюсь максимально объективно выдать содержимое этого треда, чтобы вы могли также непредвзято взглянуть
Тезис (локально) противоположной стороны, что монады это не только способ работы с асинхронными вычислениями, но и множество других применений (в которых никаких колбеков нет).
Вопрос о том насколько они удобны/нужны при этом остается за скобками. При том что в мейнстримных языках монад как явной сущности нет, есть просто вручную встроенный набор монадических методов в стандартные контейнеры.
Ваш тезис, что в асинхронном программировании монады это те же колбеки под капотом, и проблемы не решают.
С ним можно соглашаться, а можно спорить, но ваш оппонент говорит вообще о другом, защищая свой тезис и монады в целом.
Если вернуться к началу ветки, то в данном случае, изначально вопрос был поставлен про инновационность монад как примера интенсивного развития, и попытка ее опровергнуть на основе того что конкретное хорошо известное вам применение в асинхронном программировании не иновационно кажется не очень корректным.
А так вот на хабре же есть отличная статья habr.com/ru/post/429530 с очень конкретным и выразительным примером никак с асинхронностью не связанным.
Субъективно кажется, что монады и сопутствующий аппарат современного (вообще уже не столь, просто до мейнстрима долго идет, ну и каких-то фреймворках и библиотеках мощных построенных на данном подходе) функционального программирования это как собственно приход структурного программирования на смену goto (что не значит, что у него не остается области применения), но если вы не считаете и случившееся тогда инновационным, то логично что тут тоже ничего такого нет, просто куча сахара.
а в данном случае опровергать чужой тезис пришли именно вы
а у него не было тезисов. он пришёл и как всегда назвал всё демагогией и полез со своими монадами.
при том как всегда сам не понимает что такое монада вообще (правда вот выше, вроде наконец до него дошло, что промис — частный случай монады, осталось сделать ещё один шаг к ненужности и промисов и монад, который сделали даже в питоне)
Тезис (локально) противоположной стороны, что монады это не только способ работы с асинхронными вычислениями, но и множество других применений (в которых никаких колбеков нет).
попробуйте монады написать на другом языке, например на чистом JS. Получится у вас это без колбеков (или методов класса, кои тоже колбеками являются)?
если один язык, интересный чуть менее чем никому, нарисовал про монады безколбечный синтаксис, это не отменяет колбеки.
ровно так же как если другой язык нарисовал про промисы безколбечный синтаксис — это не отменяет, а просто прячет под капот те самые промисы
как-то так
как обычно — каша в голове. сходи проспись. я даже не смог распарсить тот мусор что ты сюда вывалил
если не создавать себе трудности, которые потом придётся героически преодолевать, то монады не нужны.
собственно статья именно об этом: приходит поветрие, делает всем плохо, затем приходят умники с монадами и говорят "это панацея". Если бы ранее не пришли умники с хейтом того или иного подхода (динамические типы, goto, KISS, итп) то и эта впариваемая "панацея" тоже нафиг бы никому не нужна была
Да, пришло поветрие, сделало вдруг парсерам на стейтмашинах плохо, создало проблемы, а потом героически их преодолело. Да, всё так и было.
но общая сложность осталась высокой, KISS-принцип нарушен.
Про панацею, кстати, никто не говорил.
я с тобой спорю уже лет пять. и всегда ты эти монады пихаешь. я хз. у тебя видимо процент от их продаж там в доходе?
Не будет.
будет
Где вы увидели коллбеки в List/Maybe/State/etc?
Рискну предположить, что с точки зрения автора статьи любой интерфейс, принимающий функции, в частности, любой continuation-passing - это "колбечная лапша". В том числе и монадический bind.
Призыв изучать все подряд поддержу, все остальное - точно нет.
Дело в том, что ваше "творчество" именно что никому в бизнесе не нужно, там нужен предсказуемый результат к предсказуемым же срокам. Хотите творить - творите у себя дома, выкладывайте в открытый доступ (или не выкладывайте, дело ваше), но за деньги бизнеса этот самый бизнес хочет решения своих задач в той постановке и теми средствами, которые он считает для себя оптимальными. Более того, уже на этапе, когда разработчиков станет больше одного, придется договориться о том, сколько где ставить пробелов и в каком порядке модули подключать, потому что иначе кому-то обязательно придется терпеть неудобства, и поручить применение этих правил ко всем изменениям автоматике - это экономия времени и усилий всех участников-людей.
То же самое и с отсутвием goto (от которого ушли вовсе не потому, что Дейсктра такой влиятельный, а потому, что устали бороться с настоящими проблемами, вызванными его наличием и неправильным использованием, а именно с добавленными "творцами" непредсказуемыми переходами хрен знает куда, отчего рассуждать сколько-нибудь успешно о настоящем control flow стало невозможно. Да, его можно использовать правильным образом, но мы не умеем, также как мы не умеем самостоятельно управлять памятью в Си-подобных языках. Исключения, кстати, тоже выкинули по похожим причинам - переход хрен знает куда во время выполнения программы, это не только очень грустно с точки зрения производительности, но еще более грустно с точки зрения поддерживаемости, отлаживаемости, и вообще возможности понять, что в программе происходит, может произойти, и не может произойти, не запуская ее и не имея полного набора всех возможных входных данных).
Проблема "мне дали нож для масла, он тяжелый и тупой, а я хочу скальпель - он легкий и острый" - она очень старая, но у нас тут давно уже не операционная, где один хирург оперирует, а двое ассистентов подают ему инструменты и вытирают пот со лба, а мясокомбинат, в котором вчерашние студенты без опыта очень быстро, почти не думая, лепят бесконечные котлеты, стоя по колено в фарше. Индустрия давно уже успешно доказала самой себе, что среднестатистический разработчик - это человек, который ошибается просто по природе своей, и нужно сделать так, чтобы минимизировать и вред от этих ошибок, и распространение эффектов от них, сделать их как можно более локальными и заметными, либо невозможными в принципе без специальной здоровенной таблички "ОСТОРОЖНО, РАБОТАЮТ ЛЮДИ!". И goto, и исключения, и прямой доступ к оборудованию, и ручное управление памятью, и динамическую типизацию, и права рута, и доступ к внутренностям ОС, и все похожее остальное у вас отобрали чтобы защитить вас от вас самих же, а бизнес - от ущерба, который вы наносите тем фактом, что вы обычные люди, и у вас бывает плохое настроение, неудачный день, "мозговой пердеж", недосыпание, недостаток кофеина в крови и знаний в голове. Вот это все выше - не "поветрия", а неизбежность, и ограничения подобные возникают и кодифицируются при любой совместной работе множества людей над любыми большими проектами, в которых ошибки дороги, а люди - обыкновенные люди.
Не хотите работать в таких условиях - дело ваше, но я рекомендую попробовать собрать команду из десятка таких высокообразованных нехочух, и попробовать с этим всем взлететь. Попробуете, и сами придете к большей части описанных ограничений, выяснив на личном опыте, почем фунт лиха, чем статическая типизация лучше динамической, в чем проблема с исключениями, и кто морковку под землей в оранжевый цвет красит...
В конце 19 века люди тоже хотели 8 часовой рабочий день вместо неограниченного по желанию хозяев бизнесов. И все ваши аргументы из первого абзаца применимы и к той ситуации.
Общество самоорганизуемо и если эволюционно или революционно не сойдёт с рельсов узкой специализации винтиков,как того желает бизнес для сокращения расходов и лучшего контроля, то кто через два поколения будет создавать и творить новое? Раньше творцы росли из этих винтиков которых не зажимали. Представьте что всё для бизнеса и каждый пишет только свой код перекладывая джейсонов и так будут учить везде, на всех курсах что это правильно ибо эффективно. Откуда возьмутся новые творцы?
И система бизнес-разработки начнет деградировать, все чаще обращаясь не к вышколенным своим командам и смежникам а на фриланс. И творцы все сбегут туда. Где нет регламентов а только тз-деньги-продукт. И через какое о время эти творцы опять придут в бизнес команды рассказывая новому поколению собственников как тут все у вас отвратительно и формализовано. По новому кругу :)
Современное 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!!
В конце 19 века люди тоже хотели 8 часовой рабочий день вместо неограниченного по желанию хозяев бизнесов. И все ваши аргументы из первого абзаца применимы и к той ситуации.
Вообще-то восьмичасовой рабочий день — это выгодно для бизнеса, потому что если заставлять людей работать слишком много каждый день, то в краткосрочной перспективе производительность вырастает, но потом падает ниже производительности на восьмичасовом рабочем дне.
Удивительное дело, очень часто слышу утверждение что бизнесу нужны предсказуемые результаты за предсказуемое время, но почему-то на практике бизнес делает все что б результат был предсказуемо паршивый за НЕпредсказуемое время.
Например совсем недавно один крупный и внешне успешный сервис по доставке продуктов решил переписать монолитную систему c SAP ERP на пучок микросервисов на java. Мотивация была проста: монолит сложно развивать и он тормозит, а множество сервисов можно делать независимо и они будут относительно просты и изменения вносить легче. Как итог вместо запланированных 6 месяцев на все про все, кое как уложились в 2 года и вероятно (но не точно) колоссальный перерасход средств на разработку и уничтожил успешный бизнес, остался только бренд в желто зеленых цветах.
Прямо вот сердечная благодарность за "не умеем". Мне кажется, это мало кто видит.
Я просто по теме безопасности это вижу. Да, вроде бы есть много всяких советов, практик, стандартов, как все надо делать, чтобы не плодить уязвимости. Если смотреть на видимое - можно увидеть, что мы умеем не писать SQL Injection уязвимости (есть статья-книжка, как этого не делать). Умеем использовать CSRF токены. Умеем не делать уязвимости форматной строки. Судя по видимому - для всех проблем видны решения!
Но вот постоянные взломы, утечки даже из самых известных компаний (даже сегодня). И я не считаю, что программисты (или безопасники) там дураки. Вполне может быть, гораздо лучше меня все это умеют-понимают. Но просто все советы по безопасности эффективны как совет бороться со стелс-самолетами "бей лопатой по приборам навигации". Раз на практике уязвимости есть - значит писать код без уязвимостей мы НЕ умеем. И даже то, что потом можно хлопнуть себя по лбу и сказать - "ну да, конечно же, здесь надо было вот так вот написать, я это знаю" - ничего не меняет.
Можно будет сказать, что мы умеем не совершать какую-то проблему только если будет гигант вроде яндекса и во всех его проектах за последние N лет этой проблемы не будет - тогда умеем, да. (Например, атаки на срыв стека в этом смысле побеждены).
Атаки на срыв стека в этом смысле побежденыДа если бы, блин горелый! Побеждены они буквально в паре программ, которые непрерывно атакуют, а там, где атакуют чуть менее яростно — цветут пышным цветом.
Никто там не дурак гарантировано, основная проблема в том, что вообще говоря проблемы компьютерной безопасности практически ортогональны проблемам разработки ПО.
Задача безопасника гораздо шире задачи разработчика, потому что последнему нужно, чтобы программа, грубо говоря, выдавала ожидаемый результат при ожидаемых входных данных за ожидаемое время. Платят ему именно за это, и спрашивают именно за это, и инструменты его под это заточены. Безопаснику же нужно, не навредив «правильному» пути в этом огромном дереве принятия решений, отрубить как можно больше ветвей, ведущих к исполнению произвольного кода, который атакующий каким-то образом желает исполнять. А если у нас программа еще и с секретными данными работает — дополнительно предотвратить утечку этих данных по каким-либо сторонним каналам. Т.е. борьба и с возможностью и перехода программы в «неожиданные» состояния, и с возможностью сборки из таких состояний и переходов т.н. weird machine.
Вот эти задачи — они кратно сложнее «обычного» программирования, и именно они приводят к требованиям и ограничениям, которые «обычные» разработчики потом яростно ругают за то, что они ограничивают полет их мысли и свободу их самовыражения, не понимая, что без этих ограничений, процессов, линтеров, статических анализаторов, компиляторов, и прочего тулинга даже минимально безопасное ПО написать буквально нельзя, потому что комбинаторный взрыв, потому что бизнесу это ПО нужно уже сегодня, и потому что мы тут такие же люди, как и «обычные» разработчики, и ограничены таким же образом.
Вся история компьютерной безопасности — это история борьбы все более сильных ограничений со все более изощренными методами их обхода. При этом цели сделать 100% безопасно не ставится никогда, достаточно, чтобы ценность защищаемой информации была ниже, чем стоимость неправомерного ее получения при помощи все более хитроумных (а потому все более дорогих) технических средств. И пока что, даже несмотря на буквально миллиарды долларов вложений и миллионы человеко-часов далеко не самых глупых человеков, получается у нас примерно вот так.
Срыв стека побежден в том смысле, что если вы его прямо вот очень сильно не хотите - вы просто пользуетесь простым языком без malloc() и strcpy(), каким-нибудь PHP или пайтоном - и все у вас будет хорошо. Достаточно просто распорядиться, на бумажке подписать указ "пишем проект на пайтоне", и срыва стека не будет. Есть ничтожная вероятность, что он будет в самом пайтоне, но и эта проблема решится дешево, просто апгрейдом на пропатченную версию. Да, это не абсолютно, но вполне близко к тому. Уязвимы те, кто до сих пор пишут на С, но они знают и принимают этот риск.
И мне кажется, это очень хороший подход. Нечто подобное есть в веб-программирований. Полно типовых LAMP сайтов и бэкендов сделанных студентами, в них куча дыр, но при этом вряд ли через какую дырку можно получить доступ к другой базе данных в этом же MySQL и вряд ли можно выйти за пределы юзера www-data.
Когда мы безопасность "аутсорсим" отдельному маленькому стабильному компоненту, (например, код аутентификации в MySQL) он у нас один раз вылизан до идеала, и дальше мы можем на него полагаться. Сайты пишем разные, но вот mysql и ядро с файлухой используем готовые, поэтому нарушить их барьеры практически невозможно.
Что такое микросервис, значительная часть которого кодогенерируется? Это способ изолировать разработчика от целого (и друг от друга). Это жёсткий контракт в YAML-файлах: «На входе требуется вот это, а на выходе вот то, приступай!». И даже внутри оставшихся двадцати процентов свобода творчества самым садистским образом ограничена: цензурируется шестью с половиной линтерами!
Но ведь вполне здравая идея — изолировать и абстрагировать задачи, чтобы разработчик не был вынужден сперва пару месяцев втыкать в весь имеющийся codebase, а мог работать в формате «вход-выход-приступай». Да и линтеры правда ли такое уж зло — нужно ли другому разработчику, если мы от него всё же не смогли до конца изолироваться, ломать глаза, проникаясь нашим творческим стилем кода, или всё-таки лучше видеть привычные вещи в привычных местах в привычном формате? Пример если что и показывает, так это то, что любая, даже здравая в основе своей идея, будучи доведена эффективными менеджерами до состояния самоцели, может превратиться в бессмысленный вредный маразм. Ну так а что у нас, будучи доведено до состояния самоцели, не может превратиться в бессмысленный вредный маразм?
Вообще, можете зачитать статью в аудио-формат голосом Ленина, и чтобы там ещё были всякие «батенька» и «аrхиважно»? Типа: «Товаrищи! Аrхиважно написать пrепrоцессоrы для Go и Rust, rеализующие синтаксис исключений! Немедленно захватить и ценой любых жеrтв склеить в монолит все микrосеrвисы!»
Но ведь вполне здравая идея — изолировать и абстрагировать задачи, чтобы
разработчик не был вынужден сперва пару месяцев втыкать в весь
имеющийся codebase, а мог работать в формате «вход-выход-приступай».
только тот же спектр задач, что раньше решало пять человек, в новой парадигме решают 150 и в значительно большие сроки...
И ценность для бизнеса в том, что 150 одним днём можно заменить на другие 150.
а так-то да, вы правы.
Но ведь вполне здравая идея — изолировать и абстрагировать задачи, чтобы разработчик не был вынужден сперва пару месяцев втыкать в весь имеющийся codebase, а мог работать в формате «вход-выход-приступай».
Изолирование/логическое стуктурирование/переиспользование/универсальность кода = хорошо. Урезание видимости задачи человеку/разрыв контекста/зацикливание на стандартах и паттернах/ограничение самовыражения = плохо.
Я не знаю как вам, но думаю многим специалистам не очень нравится работать по методу "мог работать в формате «вход-выход-приступай».". Я разработчик уже более 20 лет, за всю мою историю работы я не встречал хороших специалистов, которым бы нравился такой подход. Он же уничтожает личность человека, уничтожает его желание создавать. Зачем тогда идти работать разработчиком, если ты это не любишь и тебе это не нравится? Можно устроится намного проще, где не надо постоянно изучать новое, постоянно быть в "теме", постоянно учить. А если ты любишь свою работу, она приносит тебе удовольствие, значит и такой подход терпеть нельзя.
Что касается микросервисов, то я не думаю что все они плохие и их "надо запретить". Надо просто с головой подходить к проблеме которую мы решаем и уже от нее смотреть какое решение нам подойдет, если подходит микросервис - используем его, если монолит, значит применяем монолит. Это же касается и языков программирования. Просто я думаю что нельзя так категорично утверждать что "это плохо", а вот "это хорошо", мир разный и каждому найдется свое применение.
Автору удалось разбудить быстрее и лучше чашки кофе.
Боли процедурного программирования под марксистским соусом - какой-то сюр, честное слово.
Конечно, разработка - творческий процесс. Но если ты часть бизнеса, то уважай его. Не хочешь - иди в другой, слава Богу не при социализме живем.
Я не хочу учить джаву. Хочу писать микросервис на питоне, в который заверну свою нейросетку.
Что-то многие прям серьезно восприняли статью. Хоть в ней много разумных замечаний, не стоит забывать, что это пятничное :-)
ИМХО, по поводу "пролетарии всех стран" вы немного не к той целевой аудитории. Пролетариат был готов бороться, потому что ему нечего терять кроме своих цепей. Программисты, и в целом ИТ специалисты, сейчас одна из самых оплачиваемых категорий наемных работников. Хотите убедить их что лучше бороться за светлое будущее, чем зарабатывать приличные деньги прямо сейчас?
Вспомните недавний случай, rambler vs nginx, как отреагировало ИТ сообщество? Примерно никак, побурлило в комментах. Кто-то пытался предлагать разработчикам видеосервиса rambler встать и уволиться, на что они сказали, в приблизительном переводе на русский: "нам жаль, если кто-то пострадает, но у нас успешный бизнес, широкая аудитория, большие зарплаты. да вы охренели."
Кроме того, борьба это не только либиртэ-игалитэ-плюсвкарму, но и "порой прозябая по тюрьмам сырым ... и шли мы гремя кандалами". У нас, как бы, капитализм, соответственный правящий класс, поэтому условный рамблер может написать в полицию "у нас украли миллион" и к разработчикам придут люди с автоматами, изымут имущество и заблокируют счета, а через полгода скажут - отсутствует состав преступления, вы свободны. А условный разработчик, который потерял миллион в результате этих действий - нет.
Выбор который предлагаете вы выглядит примерно "бороться с режимом и получить двушечку вместо зарплаты" или "писать микросервисы без гоуту и исключений и получать высокую зарплату, пока есть возможность". Прикольно, чо? Впятницу утром бодрит лучше чашки кофе
Боже мой! Дожили! Неужели же ИТ движется в правильную сторону?!!
Ладно, спокойно. Я когда-то уже комментил, и готов посторить сейчас: ИТ (по крайней мере до этого момента) находится в состоянии допромышленного производства. Грубо говоря, средневековье с мастерами и цехами. В то время, как производство материальных ценностей уже начиная с петровских времен находится в состоянии нормального промышленного производства.
Уже начиная с Петра 1, производство ружей делалось в такой вот "микросервисной" манере - каждый мастер точил только одну определенную деталь. По чертежу, строго по размерам. Можно было разобрать десять ружей, перемешать детали и собрать снова десять ружей, и они будут нормально функционировать и стрелять. Если мастер по замкам уволится, он не сможет сделать ружье самостоятельно. Драма это? Трагедия? Нынешние рабочие точат на определенных станках определенные детали и даже подумать не могут, что могут выточить трактор целиком, если уволятся. Драма это для них? Трагедия?
Почему же для айтишника это трагедия?
Все проблемы ИТ - это средневековая отсталось организации производства, я гарантирую вам это. В программировании нет разделения труда, бекэнед/фронтенд - это вообще не разделение. В программировании нет тотального контроля результатов труда. ТДД - это полная ахинея, я уже писал. ТДД сравнивает результат труда программиста не с чертежом, а с тестом. Не может исполнитель проконтролировать свой продукт. Контроль должен осуществляться ВСЕГДА сторонним человеком, причем это должен делать не разработчик проекта, а специально обученный контролер - тестировщик. В программировании царит тотальная самодеятельность. Понятия проектов (чертежей) в подавляющем числе контор не существует, либо они крайне размыто составляются и программисты крайне вольно раеализуют свои поделки, зачастую очень отдаленно реализующие проект. Да еще и продвигается мысль, что проекты - зло.
То, от чего так бомбит автор - отчуждение результатов труда от исполнителя - это нормальный процесс развития производства. В машиностроении это было реализовано триста лет назад (Маркс только описал). Рабочие на заводе ходят на работу не для того, чтобы самовыражаться. Они делают работу, точат детали (строго по чертежу) и получают за это зарплату. В ИТ почему-то творится дичь. Приходит программист и предлагает прикрутить к огромной системе какую-то фиговину сбоку, в пятьдесят строк кода, ага. Которая решит все проблемы.
Его правильно обломали. Есть чертеж изделия (к примеру ракета или ускоритель). По нему исполнитель должен в точности выточить все детали (классы). Детали тщательно проконтролируют и соберут из них узлы (микросервис). Узлы(Микросервисы) соберут в единую систему, которую можно будет запускать в космос (в продакшн). И тут приходит дядя Вася (талантище!) который предлагает "Давайте тут приварим фигнюшку! Ракета баще полетит!". Какие слова прозвучат при этом предложении?
Когда промышленность использует человека как заменимую часть конвейера то начинает страдать психика человека. У нас почему-то психическое здоровье людей традиционно низводилось до каких-то презренных розовых соплей, которые волнуют только неженок. Но нас эволюция готовила немного под другие задачи по типу "сообща командой завалить мамонта" или "обхитрить группу противника".
Видимо из за этого так популярен футбол и командные компьютерные игры. Мозг не просто так тяготеет к творческим задачам...
Возможно. А когда пожарный на работе в огонь лезет - начинает страдать кожа пожарного, а то и до костей сгореть может. Но кому не нравится - могут работать в других сферах.
Первична какая-то бизнес-потребность, и уже для ее решения нужны программисты, тимлиды, ПМы и прочие. Но не наоборот, не ради счастья программиста все это придумано.
Главная мысленная таблетка от излишнего "социализма" - роботизация. Вот ныли раньше рабочие на какой-нибудь фабрике, что им мало платят за тяжелую работу по шитью кроссовок, угнетают их, эксплуатируют - появляется полностью автоматизированная линия и их уже не эксплуатируют. (Могут радоваться). Их очень легко заменить. Программистов сложнее, но, возможно, очень скоро и мы будем под вопросом, и никто уже не будет мучать нашу психику неприятной работой. Какой-нибудь AI заменит 80% программистов.
не ради счастья программиста все это придумано
Вот в этом принципиальная разница наших взглядов на труд. Я уверен, что бизнес и организация должна быть "для счастья программиста", а не "человек — топливо для бизнеса".
Думаю, что и сейчас полно желающих работать руками и головой, но не в качестве винтика в системе. Ведь можно организовать труд людей таким образом чтобы к рутине подмешивалась некая часть творчества, чтобы сотрудник чувствовал своё небольшое но влияние на общее дело. (Как это происходит в небольших командах, где каждый ответственен за свой участок работы).
Но я не вижу тут проблемы. Можно ведь не работать винтиком в большой компании если не нравится. Работать в маленькой компании. А другим наоборот, кому-то хочется один раз глубоко выучить одну свою тему и в ней до пенсии работать. Им это творчество нафиг не нужно, им хочется с 9 до 5, по четким правилам, чтоб как на госслужбе.
Это как с барами-кафе-ресторанами. Не надо разрабатывать кодекс, правила для меню, стандарты на размеры столов итд, а потом всех заставлять их соблюдать. Нет, пусть цветут все цветы. И то что вам 9 из 10 баров не нравятся - ну и ладно. У вас будет свой любимый веганский бар для тех кто с детьми и пришел курить, гладить кошек и слушать норвежскую музыку.
А что если не все цветы цветут и у людей не может быть выбора? Например в небольших городах. Вот в вашем городе много сравнимых вакансий, чтобы все кто не хочет работать винтиком имели возможность начать работу на новом месте?
Страдать. Вот я, например (в душе, по вкусам, предпочтениям), знаменитая мировая поп-певица и икона стиля. Но в моем городе меня не знают, не ценят, платить за это не желают (а я бы спел). Особенно люди с музыкальным образованием не любят мои песни. И мне приходится страдать и все вот эти ваши пайтоны, линукса и хттп. А мне летать, а мне летать охота. Если уж такая супер-звезда как я страдает и унижается то IT ремесла - и они не развалятся.
Как только собес будет мне платить (или законять бюджетников на концерты с билетами, как на роллинг-стоунз) достаточно, чтоб хватило на шлюх, к.каин, частный вертолет и еженедельный разгромленный номер в отеле - дальше можно уже позаботиться будет и о тех, кому хочется не одну технологию программирования, а другую.
Я удивлён как вы защищаете негуманную систему. Если честно, было трудно продраться через дымовую завесу софистики и неуместных аналогий...
А почему гуманная нереализуема? Опять какие-то ложные дихотомии и защита рабами своих оков.
Ну чёт несколько раз гуманную пытались реализовать, каждый раз выходила какая-то какашечка. Последний такой эксперимент затянулся лет на 70, последствия до сих пор разгребают.
Выборка мала. Первые самолёты падали и убивали своих пилотов, но люди не перестали развивать авиацию.
Если бы любители построить справедливое общество ставили свои социальные эксперименты исключительно на себе - это было бы замечательно.
Ну чёт несколько раз гуманную пытались реализовать, каждый раз выходила какая-то какашечка.
всякий раз антигуманисты гадили так, что
-
- проводили мировые войны на территориях где такое пытались реализовать
- сочиняли 100500 небылиц, которые теперь официально записаны в учебники (например: секретные дополнения к пакту Молотова-Риббентропа, или скажем: миллионы жертв ГУЛАГа. Последнее впервые сочинено Гитлером в произведении Майн-Кампф, а затем творчески переработано и удвоено (по числу жертв) Солженициным и ко)
- устраивали экономические и прочие блокады (Куба, Корея так до сих пор в блокадах, а Корея так ещё и разделена на две), ограничивали доступ к технологиям.
- организовывали гонки вооружений, итп
СССР в таких условиях продержался, как вы изволили выразиться, 70 лет, потому, что удалось контролировать довольно много ресурсов.
Кстати, это противостояние со всем миром показало, что теоретики, считавшие, что нужно делать мировую революцию (и проигравшие тем, кто считал, что мы свою страну сумеем отстоять), были в чём-то правы.
PS: А наложенный на нас извне железный занавес, вполне дал плоды. Люди привыкли к тому, что СМИ рассказывают им правду, а затем когда занавес приподняли и хлынула муть, получились такие как вы, рассказывающие всем про какашечки и главное: верящие в эту хрень
проводили мировые войны на территориях где такое пытались реализовать
Причинно-следственная связь сломалась.
или скажем: миллионы жертв ГУЛАГа. Последнее впервые сочинено Гитлером в произведении Майн-Кампф
Майн-кампф написан в 1925-1926 году. Гулаг начали организовывать в 1929 году. (даты взял из открытых источников). Этот Гитлер тот ещё провидец оказался ;)
я бы дал сюда цитату из него, но это запрещённая литература.
если скачаешь — можешь поиском внутри поискать по слову «репрессировано и убито тридцать миллионов».
во время войны Геббельс увеличил эту цифру в полтора раза в своей пропаганде, ну а Солженицын довёл её до шестидесяти (ЕМНИП).
> Этот Гитлер тот ещё провидец оказался ;)
в плане пропаганды-то? конечно. все запущенные им мульки работают до сих пор, как и созданные им бандеровцы и проч.
вот снова приходится с этим воевать. увы
репрессировано и убито тридцать миллионов
Не так там написано, совсем не так, и совершенно по другому поводу..
Hidden text
Самым страшным примером в этом отношении является Россия, где евреи в
своей фанатической дикости погубили 30 миллионов человек, безжалостно
перерезав одних и подвергнув бесчеловечным мукам голода других, — и все это
только для того, чтобы обеспечить диктатуру над великим народом за небольшой
кучкой еврейских литераторов и биржевых бандитов.
Вы же про гражданскую войну слышали? Или её тоже Гитлер придумал? В википедии цифры немного скромнее, 2 млн эмигрировали, 2 млн комбатантов погибли, 4 млн беспризорных детей.. Мелочь, правда?
ЗЫ: кого он имел в виду под литераторами и биржевыми бандитами, не могу сообразить. Ленин - юрист, Сталин - священник. Так себе авторитет этот ваш Гитлер ;)
надо помнить, что нацисты в целом были очень благосклонно приняты европой и потому она практически сразу под них легла
да и США, что уж греха таить: самых отмороженных палачей вывезла к себе, чтобы спасти от суда
всё это «поменялось» только тогда, когда мы стали давать нацистам укорот. И в общем даже когда укорот дали, то нацизм не перестал быть моден в европках, просто стало моветоном упоминать некоторые национальности.
и вот новые борзописцы, взяв на вооружение написанное нацистами о евреях, теми же текстами борются с Россией.
Вчерашние палачи, вымарывают список национальностей из своих текстов и формируют различные элитные батальоны для возможной борьбы с СССР. итп
PS: в том тексте, что вы процитировали, уберите «евреи» (замените на «большевики») и сравните его с современным (ну как современным, последние 30 лет продвигаемым) мемом «украинский голодомор». и получите 100% совпадение.
Европа (и США) дышала и была беременна нацизмом (как впрочем происходит и сейчас). Просто главный исполнитель имел некоторый задвиг конкретно на евреях, но это не помешало ему организовать войнушку в которой погибло их 6млн, а остальных — 64 млн.
как-то так
надо помнить, что нацисты в целом были очень благосклонно приняты европой и потому она практически сразу под них легла
Надо помнить, что СССР и гитлеровская Германия вполне успешно сотрудничали. И даже, можно сказать, воевали не в ту сторону.
Hidden text
19 августа было заключено германо-советское коммерческое соглашение
(1939). Соглашение охватывало «текущий» бизнес, который подразумевал
обязательство СССР поставить сырье на 180 миллионов рейхсмарок в ответ
на немецкие заказы, в то время как Германия разрешала Советам заказывать
немецкие промышленные товары на 120 миллионов рейхсмарок[98][99][100].
Согласно этому соглашению, Германия также предоставила Советскому Союзу
товарный кредит в размере 200 миллионов рейхсмарок на 7 лет для покупки
немецких промышленных товаров[101] по чрезвычайно выгодной процентной ставке[99].
Hidden text
11 февраля 1940 года Германия и Советский Союз заключили сложный
торговый пакт, который был в четыре раза больше, чем тот, который две
страны подписали в августе 1939 года[122]. Торговый пакт помог Германии преодолеть британскую блокаду Германии[122].
В первый год Германия получила миллион тонн зерновых, полмиллиона тонн
пшеницы, 900 000 тонн нефти, 100 000 тонн хлопка, 500 000 тонн фосфатов и
значительное количество другого жизненно важного сырья, наряду с
транзитом одного миллиона тонн соевых бобов из Маньчжурии. Эти и другие
грузы перевозились через советские и оккупированные польские территории,
что позволило нацистской Германии обойти британскую морскую блокаду[122].
Советы должны были получить морской крейсер, чертежи линкора «Бисмарк»,
тяжелые морские орудия, другое военно-морское оборудование и тридцать
новейших немецких военных самолётов, включая истребитель Bf 109,
истребитель Bf 110 и бомбардировщик Ju 88[122].
Советы также получат нефтяное и электрическое оборудование, локомотивы,
турбины, генераторы, дизельные двигатели, корабли, станки и образцы
немецкой артиллерии, танков, взрывчатки, оборудования для химической
войны и другие предметы.[122]
Советы также помогли Германии избежать британской морской блокады,
предоставив базу подводных лодок «Базис Норд» на севере Советского Союза
вблизи Мурманска[123].
Это также обеспечило место для дозаправки и технического обслуживания, а
также взлетную площадку для рейдов и атак на судоходство[123].
Англы воюют с немцами, немцы бомбят Лондон, СССР помогает немцам с морской блокадой.
дык мы и сейчас успешно поставляем нацистской европе газ и нефть. Зачем мы это делаем? Снова думаем: «авось не нападёт!»
причём мы так думаем, несмотря на устроенное на украине
дык мы и сейчас успешно поставляем нацистской европе газ и нефть.
Сотрудничать с нацистами - в этом же нет ничего плохого, правда? ;)
но она всё равно укусит. в этом ошибка и СССР и современной России.
сотрудничество полноценное, это например то, что мою родную деревню, из которой у меня предки по маминой линии, оккупировали не немцы, а французы, пришедшие с вермахтом.
причём мы так думаем, несмотря на устроенное на украине
Эээ, кем устроенное? Европой?
То есть это они войска на Украину ввели и "спецоперацию" начали?
Что же сложного? Давайте я помогу. Вы хотите быть программистом, делать что-то конкретное (а не то, что от вас хочет злой наниматель) и получать за это хорошие деньги (в отрыве от рыночного спроса на это действие). А я хочу быть Софией Ротару, ездить с гастролями, собирать полные залы, принимать цветы, ну и получать за концерт соответственно. И мое и ваше желание не сбывается сейчас. Почему вы считаете ваше желание более важным, приоритетным, чем мое?
В "негуманных системах", как мы видим на практике, всем ущемленным группам (пенсионеры, инвалиды, безработные) - живется гораздо лучше чем в "гуманных" системах.
А бизнесменов можно заменить роботами?
В каком-то смысле. Посмотрите на магнит, типичный управляющий магнита делает почти те же функции, что и хозяин небольшого магазина. Просто исполняет программу.
Но в другом смысле невозможно, потому что бизнесмен рискует своими деньгами, когда вкладывает их в какой-то бизнес. А робот так не может, потому что у робота своих денег нет. Робот может, например, заказать новую партию товара, но вот рисковать он не может, ему нечем. :-)
А что даёт риск человеку и не даст роботу?
Обратную связь. Хороший предприниматель сегодня открывает ларек шаурмы, через год у него сеть ларьков, а через 10 лет ему все рестораны лас-вегаса принадлежат. Потому что он умеет каким-то образом делать хороший общепит и превращать один доллар в десять. А кто не умеет - тоже полон идей, но как только проверяет их, открывает свою первую шаурмячную, и остается ни с чем.
Но на самом деле я чуть преувеличил. Дурак (там, внутри себя) понимает, что он дурак. Ему нравится обманывать себя, будто бы он умный, но как только дело доходит до того, чтобы вложить 100 тысяч и своим умом получить из них миллион - что-то в дураке говорит ему - "не надо, ты же дурак, твои идеи - говно, они не взлетят" - и он не вкладывает.
Вот у робота нет ни денег, ни внутреннего голоса, ни страха потерять деньги.
Кто мешает дать роботу свои деньги или ввести какие-то иные квоты на его деятельность?
Откуда эти деньги возьмутся?
Пусть сами себе намайнят ;)
Упсь, даже самый тупой робот быстро сообразит, то нужно вкладываться не в производство, а в криптовалюты ;)
Выходим на ИПО, допустим, торговым бизнесом. ставим AI на прогнозы продаж/закупок, формирование долгосрочной стратегии, HR, в Уставе прописываем, что последнее слово всегда за нашим прогнозным АИ, выкупаем все акции с биржи, в качестве жеста доброй воли продаем свои 51% той же фирме. Все — у нас есть контора состоящая из принимающего решения AI и наемных работников.
Для этого вы должны сначала определиться, будут ли роботы работать в нынешней системе, постепенно заменяя хозяев средств производства, или мы проектируем экономику с нуля.
Откуда сейчас берутся деньги на открытие бизнеса?
А вот «изучить баг/фичу», «разобраться и придумать, что именно нужно переписать в коде» и «переписать код» разделять между людьми неэффективно — тут возникает ситуация, когда «самому сделать занимает 5 минут, а объяснять кому-то другому — 5 часов».
И с тестированием порой та же ситуация. И с нестрогим разделением на бэкенд/фронтенд.
А так, если максимально разделять, то можно дойти и до «кодеров», каждый из которых умеет дописывать в файл лишь один определённый символ и «начальника отдела кодинга», который в правильном порядке отдаёт команды, чтобы написать программу — полное разделение «творчества» и «кодинга». Вот только творчества в такой системе останется столько же (оно просто перейдёт на уровень выше), а затраты и время на коммуникации повысятся.
На ракету есть полный комплект чертежей, спецификаций и прочей документации. А не ТЗ в стиле "сделай, чтобы через полгода уже на Луне высадились, детали уточни у маркетологов. И не затягивайте, вопрос на контроле у самого вице-президента". Какие исходные условия, такие и технологии используются для их исполнения. Странно, что каждый раз, обсуждая софтверную индустрию, приплетают ракеты, токарей и прочее материальное производство.
Микросервисы - это современный конвейер. Каждый рабочий на конвейере выполняет свою маленькую задачу. Вообще история автопромышленности это история любой современной индустрии. По ней легко увидеть куда идет и IT в том числе.
А до конвейера, были фабрики, а до этого мануфактурное производство:
https://www.marxists.org/russkij/marx/1867/capital_vol1/25.htm
"...После разделения, обособления и изолирования различных операций рабочие делятся, классифицируются и группируются сообразно их преобладающим способностям. Если, таким образом, природные особенности рабочих образуют ту почву, на которой произрастает разделение труда, то, с другой стороны, мануфактура, коль скоро она введена, развивает рабочие силы, по самой природе своей пригодные лишь к односторонним специфическим функциям. ..."
Я не понял главнго. Рост деструктивных паттернов в программировании - результат злых капиталистов и отчуждения труда писателей микросервисов? Риалли?
Например, один из микросервисных программных продуктов, разработанных под моим руководством, пишет географически распределённая команда разработчиков в течение примерно 15 лет. Большинство из первоначальных участников проекта поувольнялись. Поменялось железо, операционная система, средства разработки, отчасти языки программирования. До кучи поменялось юридическое лицо.
Кто и как тут должен был бы собирать монолит?
Думаю, что Яндекс.Такси тоже устроено непросто.
Начало статьи хорошее, а в итоге автор почему-то взъелся на микросервисы, хотя претензии у него были к регламентам.
Я не программист, но мне кажется проблема общечеловеческая и выглядит как повторяющийся шаблон: "Мы придумали новую парадигму и начинаем внедрять её везде где можно как новую идею, способную решить все проблемы!".
Потом когда общество уже не может отрицать очевидные проблемы и нестыковки то начинается пересмотр (иногда весьма болезненный или даже кризис) и выдумывание новой очередной сверхидеи.
А разгадка проста — человек мыслит эмоциями и авторитетами, а лозунги являются чем-то вроде информационных паразитов мышления.
Думаю, что без них не обошлось. Ха! Забавно. Ткнул в случайное место на картинке и попал точнёхонько в "оправдание системы". Выше в комментариях несколько наглядных примеров, в духе "Надо продолжать страдать", "Роботу удавку на яйца в виде мат. ответственности не накинуть, а человеку — можно" и все в таком духе.
Отчуждение труда
Разве за использование марксистской лексики еще не начали бить канделябром?
Увы, новые вещи (коих не так чтобы вообще есть16) всё чаще приносят с собой и очевидно деструктивные, будто навязываемые извне, паттерны.
Новые вещи есть, но их нет, понемаю. Правда, потом автор вспоминает про несуществующую новую гошечку, но ее же нет. Хотя она есть.
В общем, как-то раз один с виду вроде бы неглупый человек ляпнул в
публичном пространстве совершенно необоснованное суждение "о вредности
оператораgoto"
Вредность оператора goto - в том, что получается лапша, а не код. То, что есть случаи, когда его использование позволяет выиграть несколько тактов - это, конечно, замечательно. Было. Лет 40 назад. Сейчас его недостатки перевешивают достоинства.
А ещё в наше пространство вторглись линтеры, не только верифицирующие
код на предмет возможных ошибок (что в целом хорошо), но и указывающие
нам, "сколько пустых строк ставить между блоками", или "в каком порядке
импортировать модули15!"
Линтер выдает рекомендации по code-style, ужас! Заставляет писать так, что бы тебя потом поняли другие - возмутительно!
И вот, крупная международная корпорация, для разработки нового
инструмента привлекает одного некогда умного, но ныне довольно
старенького, ставшего маразматиком, специалиста. И всё бы ничего, но
только он толкнул в массы новую "мегаидею" (по аналогии с "goto— это плохо"): "Исключения — это плохо!"4.
Это место просто офигенное. Авторы решили, что исключения как отдельная сущность не то, что бы нужны, и выкинули их. Вроде, где-то даже был rationale, почему так. Это называется "поиск идей". Правда, выше автор говорил, что нового не бывает, а тут у нас уже новое, ну да ладно.
С технической точки зрения (производительность, количество кода и т.п.), микросервис всегда может быть замещён обычным кодом, и это действие приведёт к тому, что накладные расходы упадут, а эффективность вырастет.
Серьезное заявление. Обосновывать ты его, конечно, не будешь
На самом деле, дальше я уже даже не знаю, что комментировать, потому, что там смешались в кучу кони, люди, BLM, SJW, Маркс, Руссо и свобода творчества.
Если попробовать вернуться к сути. Программирование за деньги - это ремесло. Это не искусство, где автор самовыражается на потеху себе и/или публике. Это ремесло, работа, профессия, как строительство, ремонт автомобилей и покраска заборов.
Два. Вам не нравятся новые подходы в программировании и хочется самовыражения? Вас ждет увлекательный мир опенсорца и большого количества языков программирования, включая эзотерические.
Итого. Я вообще не понимаю, что хотел сказать автор, и зачем.
Разве за использование марксистской лексики еще не начали бить канделябром?
буржуазия пыталась продвигать необходимость такого действия, однако "ветер истории неизбежно сметает нанесённое".
Вредность оператора goto - в том, что получается лапша, а не код.
а полезность в том, что из лапши можно сделать код (парсеры, стейтмашины, оперирование связанными ресурсами итп)
буржуазия пыталась продвигать необходимость такого действия, однако "ветер истории неизбежно сметает нанесённое".
И именно поэтому марксизм отправился именно туда, где ему самое место - в музей
а полезность в том, что из лапши можно сделать код (парсеры, стейтмашины, оперирование связанными ресурсами итп)
А можно сразу написать код и не сношать мозги себе и окружающим
Нелюбовь к микросервисам, скатывающася к псевдонаучным теориям. В данным момент 10 плюсов у статьи. О времена, о хабр!
Пользуясь случаем, хочу заметить, отличный механизм кармы на ресурсе. Прям видно какая у ресурса становится аудитория, и какой контент она хочет видеть.
У всего есть свои плюсы и минусы, и нужно понимать что где использовать.
Например, есть задача сделать новый проект и команда в 50 бэк-разработчиков (и объем функционала соответствующий) - делать проект монолитом - это погрязнуть в бесконечные споры по коду и мерж-конфликты. Плюс сложность входа для новых программистов будет заоблачной.
Если же разрабатывается новый проект с 1 бэк-разработчиком, и если поделить проект на 30 сервисов - то проект никуда не сдвинется. Потому что только по одному взаимодействию этих 30 сервисов придется сделать большой объем работы, с которым 1 программист не справится.
Ну и еще есть куча особенностей (той же невозможности одному программисту своровать весь проект, когда есть доступ только к одному сервису и все) и тонкостей.
Свобода - это осознанная необходимость
Если ты осознаешь зачем тебе тут goto и можешь сделать так, чтоб поняли коллеги - пиши goto.
Если ты считаешь, что нужна штучка с postgre и можешь это обосновать (архсовет или что-то там) - делай.
ИТ абсолютно свободен, просто промышленный ИТ не для одиночек, а для команд и чем больше команда тем сложнее (а чаще всего просто лень) вот это «обосновать».
В итоге поленился и решил, что проще поменять место работы, как-то так выглядит 🤷♂️
За обработку ошибок в rust и go обидно. Не понятно почему автор воспринимает возможные ошибки в программе, как "грязь", как будто там код подгадился:
И теперь тысячи — нет, уже миллионы — программистов в каждой первой функции пишут повторяющийся код, засоряющий пространство на экране
Если вы пишите что-то серьезное, где не хотелось бы терять данные пользователей просто так, то ошибки такая же важная часть кода, как и бизнес логика, и им нужна нормальная поддержка со стороны языка и синтаксиса.
Как исключения вам помогут? Максимум у вас код в проде упадет где-то, вы это залогируете из эксепшена, и потом в этом месте добавите логику для фикса бага. Но данные уже не вернуть.
В go/rust вы сразу знаете все места где у вас упадет код, и в зависимости от контекста и важности функции, сразу можете корректно обработать этот случай.
Если вы пишите что-то серьезное, где не хотелось бы терять данные
пользователей просто так, то ошибки такая же важная часть кода, как и
бизнес логика
тут согласен.
непонятно только зачем обработкой ошибок загромождать программисту работу над собственно алгоритмом?
Вопрос- как без исключений решить следующую проблему:
Обработка пользователей в цикле
Падает ошибка, один из пользователей по какой-то причине не валидный
цикл прерывается, все пользователей после него не обрабатываются
При наличии эксепшенов, просто заворачитваетс в try catch, и ошибка не останавливает весь цикл.
Что делать без использования эксепшенов? Навешивать if на все поля, на все возможные случаи (что уже на грани фантастики, "как писать без багов")? Как это решится в go/rust?
А вот как вы в преведённом вами примере вернёте из метода отделный список ошибочных пользователей, чтоб вышестоящий алгоритм или человек мог с ними что-то сделать?
А можете пример привести? Потому что go не знаю, а быстро не разобраться.
Не получится ли так, что через maybe и optional можно предусмотреть только те ошибки, о которых ты можешь подумать? Меня интересует случай, когда ошибка случается, то есть та, которую не предвидели. Цикл прервется или нет, с использованием методов maybe и optional, при возникновении непредусмотренной ошибки?
А вот как вы в преведённом вами примере вернёте из метода отделный список ошибочных пользователей, чтоб вышестоящий алгоритм или человек мог с ними что-то сделать?
А никак. Только у вас вопрос демагогический немного- необязательно возвращать отдельный список, что бы с ним что-то сделать. Если сразу хочется, в обработке исключения можно ложить в лист, после цикла у вас будет список необработанных пользоветелей. Или помечать в базе через флаг, что бы не потерялся, и потом уже с ним работать.
Обработать весь массив пользователей, а затем вернуть массив невалидных пользователей:
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"), чтобы не распространять неопределённое поведение дальше по программе.
Жесть то какая.
На моем текущем проекте (java/kotlin) есть порядка 30 подключенных по ресту рекламных сетей, занимающихся маркетингом. Они все имеют своё апи. Им шлются юзеры, регаются, потом они опрашиваются, от них по апи приходят статусы. У нас все это завернуто в for. Иногда они в одностороннем порядке меняют апи (урлы, респонсы), и естественно валятся ексепшены. Но, так как в цикле каждая итерация завернута в try catch, отлетает только один брокер.
Теоритически это можно и на go сделать, как я понял заворачивать в потоки, и я так понимаю отслеживать состояние, типа упал panic или нет, но это же п****ц какой-то для такой тривиальной задачи.
Ну или подключать всякие mq очереди, но опять же, это по сути костыль.
Раньше поглядывал на go, но теперь точно не буду- это слишком жесткое ограничение на уровне языка. Интересно, как try catch в rust выглядит.
Вся шутка в том, что это был Rust, а обработка ошибок в Go мне самому не нравится :) и try catch в Rust нет, вообще никакого
А for у вас по чем, коллекция интерфейсов? Ну в расте будет коллекция Box<dyn SomeTrait>, где у SomeTrait есть функция опроса конкретного API, возвращающая Result<T, Err>. Err может быть общий для всех API или уникальный для каждого конкретного.
Почти любой код на исключениях переписывается на Result в более явном виде. А для типов-сумм для объединения исключений уже давно придуманы всякие thiserror и anyhow.
Ну и что тут многие не могут освободиться от try/catch в пользу монадической обработки ошибок или банального Result<T, E>, так это печаль конечно. Ибо это эквивалентные модели control flow при наличии поддержки языком программирования соответствующих операторов.
В third-party api в ответе тип поля поменяли с типа Long на тип String. Вместо циферок теперь буквочки. Как это станет известно?
У вас есть в модели nonnull поле. Такое же было в базе данных, но джун убрал это ограничение, и теперь часть данных не может смапится из базы в модель. Как это станет известно?
Я думаю, что можно найти и другие примеры. Это не может быть известно. И каждый такой чих обрабатывать с моей точки зрения, глупо. Время разработки в космом улетит, если каждую строчку кода или вызов библиотеки, которая может изменится, обкладывать if-ами на все случаи жизни.
Обычно такие штуки делаете не вы сами, а библиотеки. Что делать в случае, если библиотеки кидает panic при таких ошибках? Свои писать?
Эта ерунда — на границе с внешним миром. Вам там всё равно придётся проверять и обрабатывать кучу вещей, вроде 500-ой ошибки от сервера или лоад балансера, разрыва соединения с БД, по иным причинам несовместимой схемы, и так далее.
Это ерудна кратно увеличивает время разработки. В десятки раз. Только что ради прикола посмотрел что go выдает в делении на ноль
panic: runtime error: integer divide by zero
Вы предлагаете при каждой операции деления в проекте проверять, не является ли делитель нулем? Вы предлагаете каждый такой похожий случай (который может вызвать panic) обрабатывать?
Ну, это все частные примеры- сложно подобрать прям реалистичный. Глобально меня интересует ситуация, когда ошибка уже допущена в коде. Попробую еще пример- джун допустил деление на ноль, на ревью пропустили, тесты прошли, код на проде.
Мой основной вопрос в том, что panic в go, как я понимаю, никак не хендлится- try catch отсутствуют, и вслучае чего, если это произошло в главном потоке- всё, полная остановка приложения. Это так?
Джун написал свою функцию деления? Зачем, чем его стандартная не устроила?
Ох и любите вы до примеров доколупаться. Я имел ввиду что он написал что-то вида
package main
import "fmt"
func main() {
var b, c int = 1, 0
fmt.Println(b / c)
}Но уже не важно, я гугланул ответ. Есть способ, но как вы и писали, это не в стиле го. В стиле го пытаться проверить переменные перед операцией.
но достаточно, чтобы не хотеть на нём писать
Я уже тоже, спасибо.
Как исключения вам помогут? Максимум у вас код в проде упадет где-то, вы это залогируете из эксепшена, и потом в этом месте добавите логику для фикса бага. Но данные уже не вернуть.
В go/rust вы сразу знаете все места где у вас упадет код, и в зависимости от контекста и важности функции, сразу можете корректно обработать этот случай.
Вообще-то исключения и коды ошибок функционально эквивалентны - всё что можно сделать одним инструментом можно сделать другим. Разница только в синтаксисе и, естественно, реализации. А синтаксис у исключений лучше по той простой причине что они прокидываются выше по стеку вызовов неявно. Дело в том что мест в коде которые могут завершиться неуспехом много, а мест где по этому поводу можно предпринять какие-то осмысленные действия - мало, поэтому в подавляющем большинстве мест обработки ошибок они просто прикидываются выше. Делать это явно - неблагодарная рутинная работа, и в результате получается раздутый код в котором за обработкой ошибок не видно реальной логики. Выше есть замечательный пример из ядра, он на четверть состоит из обработки ошибок. В rust эту проблему нивелировали до предела позволив прокидывать ошибки одним !, но по мне так даже это слишком много - визуальный шум и необходимость низачем держать в голове вызовы которые могут вернуть ошибку никуда не исчезли.
Пример - загрузка файла в каком-нибудь офисе. Нужно открыть собственно файл, прочитать, раз'zip'овать, распарсить xml, переложить во внутреннее представление, при этом только в парсинге xml может быть куча разных типов ошибок. Но сделать мы с этим ничего не можем - файл в любом случае битый. Структура кода будет одна - последовательность вызовов реализующая шаги загрузки, и обработка ошибки в одном месте где мы просто говорим "не шмогла". При желании обрабатываем конкретные типы ошибок с дополнительной информацией и говорим "не шмогла потому что в foo.xml не закрыт тэг <foo> в строке 79". Так вот код загрузки может быть либо кодом загрузки, либо кодом загрузки перемешанным с прокидыванием ошибок. Лучше однозначно первое.
Если вы пишите что-то серьезное
А если нет? Не всегда пишется код для медицинского аппарата, самолета или атомной станции. Иногда пишется код заказа пиццы или даже вот такси или покупку билета. Получить правильное решение через три года или почти правильное через месяц? Часто второй вариант лучше, потому что через два месяца рынок займет конкурент.
Эксепшн - отличная штука, это готовый код по умолчанию, который роняет приложение (ну или можно его (необработанное кодом на песте исключение) поймать и иначе обработать). Очень часто это вполне неплохое решение для непредсказуемой редкой проблемы. Признаюсь, у меня есть один код, который иногда ловит странные эксепшны по разным редким сетевым проблемам, и тупо перезапускается. Некрасиво может? Да и ладно. Но со своей задачей он справляется не хуже того кода, который бы все эксепшны в каждой строчек проверял.
Для разных проблем нужны разные решения.
Задача аналогична ваше: взять пачку данных из сети (допустим Кафка) и переложить в три другие БД (допустим постгря, http сервис и другая Кафка). Перекладывать надо exactly once, дедупликатор потом не поставить. И тут начинается обмазывание всяким и кучи обработчиков всего. И гарантии везде в коде.
Ну если вы по условиям задачи выбрали, что все ошибки надо учитывать и тщательно обрабатывать - ну ок. А чем гошный подход (через data, err := ...) в этом случае легче, чем через эксепшны?
Мне кажется, вы выбрали сложную задачу, ну ее и так решать сложно и сяк - тоже сложно.
Про goto - прошлось как-то изучать коды FreeBSD, и сразу вспомнил анекдот
"Вовочка,заглянув через замочную скважину в спальню родителей, заметил - И эти люди запрещают мне ковырять в носу"
Так что если противно использовать goto, то выключайте все свои Маки, не пишите электронную почту и не ходите в Инет ))
Маркс писал об отчуждении от результатов труда в экономическом смысле. Технически такое отчуждение выполнялось задолго до возникновения капитализма, когда, например, соборы строились по нескольку столетий (сейчас, кстати, такие длительные проекты вновь стали невозможными, уже по экономическим причинам).
вроде бы неглупый человек ляпнул в публичном пространстве совершенно необоснованное суждение "о вредности оператора
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". Но в истории остался заголовок.
я знал что вам понравится :)
Я Вас поддерживаю. Против использования goto ничего не имею - в правильном месте и в правильном контексте сильно улучшает читаемость кода. Главное - понимать где он этот правильный контекст и иметь чувство меры.
За Dijkstra стало обидно.
Вполне возможно, что взглянув на последующую вакханалию, Дейкстра признал бы сказанное ошибкой, но, увы, что бы он ни имел ввиду, а случилось именно то, что случилось.
Как он мог признать ошибкой то чего не говорил? Это из разряда "ты уже перестала пить коньяк по утрам?"
именно его статья родила что родила
даже если он имел ввиду другое, всё равно, это его ошибка.
Может дело не в том что Дейкстра имел ввиду не это? Может разработчики обратили внимание на эту проблему, подумали и решили пойти дальше и глубже, а ошибка подтверждать такие решение его словами? Сейчас goto массово не применяется по многим причинам, но жалоб что-то не особо много.
И при этом замены только развиваются: из последнего что видел и может заменять goto - это возможность писать тело лямбд снаружи от вызова функции в kotlin, прям кайф. Понятно что это не прям для этого сделано, но как способ организации потока управления прям мощь
но жалоб что-то не особо много.
странно бы было слышать жалобы из гетто, согласитесь?
Вряд ли их даже кто-нибудь запишет
Нет не соглашусь. Тут нет гетто - при желании получить этот оператор можно так или иначе. Это прям толсто - теория заговора во всей красе.
Высказать свое мнение может каждый, прилагая аргументы. Текущее положение с оператором goto это результат развития понимания программирования, инструментов и индустрии.
Аргумент в статье незначителен - не опровергает причин отказа, аргументы приведенные в коментариях слабые. Сильных вы не приводите
Высказать свое мнение может каждый, прилагая аргументы
но решение примет один - представитель крупной международной корпорации
Вас как будто заставляют Go использовать. Языков вагон, не нравится Go - используйте раст, джаву, плюсы, kphp, c#, erlang, вариантов вагон.
Вас как будто заставляют Go использовать
Именно заставляют. Сравните:
То, что принуждение экономическое, то, что отсутствует надсмотрщик с кнутом, не отменяет факт принуждения, правда?
Я сразу скажу, что у вас ошибка в методологии - многие компании не публикуют зп. Сравнивать деньги по hh в IT плохая идея.
Алсо за те же деньги можно писать на джаве, котлине и шарпе, где исключения есть.
Алсо за те же деньги можно писать на джаве, котлине и шарпе, где исключения есть.
раб свободен поесть перед работой на плантации, либо после.
вывод - рабы - свободны и разговоры об их освобождении - мишура.
как-то так
По существу-то есть что ответить? Кто вас заставляет писать на Go? Аргумент про деньги опровержен, что еще осталось?
Вы как человек, который на приеме у хирурга с лампочкой во рту жалуется на диктатуру производителей цоколей E24.
Аргумент про деньги опровержен, что еще осталось?
отвергнут != опровергнут
Бремя доказательства лежит на утверждающем, так-то. Предоставить нормальные данные - ваша отвеcтвенность
Ну да ладно, на дворе пятница, не время говниться. Давайте я пойду вам навстречу и краткости ради соглашусь, что hh - хороший источник данных:
581 вакансия «программист Go»
от 275 000 руб. 69
Работа программистом Java в Москве, 1 865 вакансий
от 285 000 руб. 118
Работа программистом C# в Москве, 917 вакансий
от 250 000 руб. 94
500 вакансий «программист kotlin»
от 285 000 руб. 45
Покажите на кукле, где вас экономически принуждают.
Бремя доказательства лежит на утверждающем
я считаю что привёл достаточно доказательств: в 10 раз различное количество предложений на рынке труда - вполне качественная характеристика
Как я уже сказал, данные с 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
очевидно не подтвержден, и даже почти опровергнут
но количество вакансий - вторая цифра
многие компании не показывают бюджет, а многие показывают
у раба есть альтернативы когда есть паёк, да
извините, я за рулём
Однозначно - отменить все языки кроме ассемблера! А за фреймворки расстреливать!
А заодно и автоматические коробки передач и автоматику в автомобилях отменить - они лишают водителя творчества.
Однозначно - отменить все языки кроме ассемблера!
отказ от исключений - шаг назад, к ассемблеру
отказ от динамического вычисления типов (перекладывание этой проблемы на плечи программиста) - шаг назад, к ассемблеру
Очень рад, что Вы имеете мнение приблизительно коррелирующее с моим: всё это - деструктивные шаги.
отказ от динамического вычисления типов (перекладывание этой проблемы на плечи программиста)
Вы специально построили фразу так, как будто это одно и то же, несмотря на то, что второе - даже не строгое подмножество первого, а вообще пересекается только частично?
отказ от динамического вычисления типов (перекладывание этой проблемы на плечи программиста) - шаг назад, к ассемблеру
Так вот динамическая типизация по сравнению с нормальной статической (Хиндли-Милнер и т.д.) — это и есть шаг назад. Питон обычно сложнее Хаскеля, т.к. в программе на Хаскеле вам IDE рассказывает, какой у вас там тип, а в Питоне приходится самому вычислять.
ассемблер - это блаж, абстракция поверху трушного бинарного кода
— Потому что эта функция запускается один раз в сутки. Даже если время её исполнения будет равно 600 секундам, то это всё равно будет устраивать абсолютно всех пользователей.
А потом приходит кто-то и именно эту функцию вызывает прямо во внутреннем цикле всего-то 1000 раз и все виснет конкретно на 6 секунд. Из за этого (потому что тикет не написали и никто уже не помнит в чем суть) запускают еще 10 серверов – и хорошо, если функция масштабируется хорошо, а вполне возможно, что и нет – ведь эта функция запускается раз в сутки, зачем делать ее масштабируемой.
И это не гипотеза. Я такое видел тысячу раз. Поэтому, если можно сделать за 600мкс, а сделали за 6мс, то это однозначно техдолг. Возвращать его или не возвращать, это время покажет. А тикет должен быть. Пусть постоит есть-пить не хочет.
Практически любому примеру противопоставляется контр-пример.
Только вероятность подобного близка к нулю
Вы наверно из тех кто думает в что корзине товаров не бывает тысяч единиц товара и можно не париться с обработкой того что там? Квадрат, так квадрат. На типичной корзине в 10 единиц все равно никто не заметит.
Или из тех кто считает что воон в тот массивчик вам никогда не передадут миллионов 100 значений? И можно его оптом сгрузить в БД, например.
Техдолгом это станет тогда когда функцию начнут запускать 1000 раз. И даже не тогда, а когда раздражение/потери превысят уровень оценки рисков того, что "оптимизация" а) сожрет кучу времени разработчиков б) будет работать неправильно и кто-то попадет на деньги. Тоже такое "видел тысячу раз"
Не согласен. Техдолгом это становится сразу. Но не все долги надо отдавать. Но дело в том, что надо возвращать или нет станет понятным намного позже. И поэтому весь техдолг надо документировать. Чтобы не забылся.
А автор выступил за то чтобы об этом техдолге просто забыли (скрыли?). Наверное чтобы не портить статистику. Самообман чистой воды.
Это странно честно говоря, в любом проекте 99.9% функций можно еще ускороить, значит ли это на все это надо оформлять как тех долг?
Если знаете как сделать – примерно поменять алгоритм, то да, надо оформлять. Если сознательно сделали медленнее, чем можно было (из за разных соображений) – то тоже да. А если не знаете как сделать быстрее, то, конечно не надо ничего писать. Ну или завести один тикет: "Помни, что весь этот код можно улучшить."
При распространенности такой практики в проекте заводить этот тикет можно сразу в dev/null ибо никто о нём более никогда не вспомнит. Уж лучше коммент чиркануть к методу о возможности его оптимизации и примечание в доке о сценарии использования, тогда хотя бы есть шанс что на это обратят внимание, когда захотят использовать его не по назначению или таки столкнутся непосредственно с проблемой его быстродействия.
"Техдолгом это становится сразу. " сразу после чего? после коммита фичи?
PS Если долг не надо возвращать, то почему это долг ибо долг сам по себе есть обязательство возврата? :)
Ну, вы забыли что долг начинается сразу как только его возмем. А возвращать надо через какое-то время (поэтому и долг). А срок может быть разным. И еще долг можно списать. Так что нет противоречия. Техдолг становится техдолгом как только коммитим код с компромиссами.
Ещё раз почитайте дефиницию: если что-то не надо возвращать, это не долг.
В любом коде есть компромиссы: там мы приносим в жертву читабельности производительность, а там наоборот (за исключением откровенных тривиальностей) Любое техническое решение есть компромисс.
И во всех случаях хорошие разработчики это документируют.
Сурово оптимизированный код где читабельность принесена в жертву обвешивается огромными комментариями. Иногда даже со ссылками на научные работы. Почему так, зачем это тут вообще и как это работает.
Явно неоптимальный код требует заведения тикета с текстом о том как его оптимизировать.
И можно жить. Следующее поколение разработки работающее с вашим кодом вам спасибо скажет.
ну долг был, был. А потом весь модуль закрыли, вместе с долгами. Так что бывает так что долги можно и списать
Поэтому, если можно сделать за 600мкс, а сделали за 6мс, то это однозначно техдолг.
Есть такая вещь, как "nonfunctional requirements". Если по ним 600 мкс достаточно, значит их достаточно. Если они (requirements) поменялись, и стало недостаточно, то только тогда и надо переделывать.
Является ли код техдолгом или нет определяется тем, соответствует ли он требованиям или нет, отражает ли он ту реальность, под которую его собираются использовать. И если отражает, то это не тех долг. Если практика применения кода измениась так, что код не отображает ее, то это уже тех долг. И это только опытом познается. Это частный случай философского вопроса об истинном и ложном знании, применительно к разработке.
Это процесс называется "пролетаризация", ранее ему подверглась интеллигенция типа врачей, учителей и инженеров.
Хочется лишь сказать: всё циклично!
Придет время, когда откажутся от избыточной микросервисности и вернутся к классике "Premature optimization is the root of all evil".
По этой логике следовало сначала выпустить первую версию, снять стату, может даже не пришлось бы сервис развивать, а закрыли бы за ненадобностью. Неужели нельзя было мертики снимать Яндекс.Метрикой?
Какой толстый троллинг всех и вся. Мне понравилось.
А что, при правильно выстроенном монолите не происходит отчуждения результатов труда? Так то правда в ней есть — одних макак легко заменить на других — один хрен так же неэффективно будут ковырять громоздкий сервисмеш.
но ви таки считаете, что с монолитом такое нереализуемо? Вы несколько ошибаетесь. И наивно думать, что унеся унылый монолит домой и будучи способным его запустить — от этого так сильно пострадает работодатель. Голая ИС без бизнеса и кучи людей, которую они наполняют данными и кучи неайтишных спецов — ничего не стоит сама по себе.
И да, зачем по дедку кену томпсону проехались? У него была цель простой как молотое понятный язык запилить для айти-макак. Он ее выполнил.
Автор, расскажу вам про один язык программирования, а точнее, про семейство языков, я думаю, вам понравится. Это 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. Язык красивый, но использовать не буду, т. к. люблю статическую типизацию.
Добавлю, что в этом моём комменте нет шуток. Сарказм, может, есть, но шуток нет, т. е. каждое предложение нужно понимать буквально, а не наоборот
Так что попробуйте, думаю, вам понравится.
Дык я пользуюсь, мне нравится :)
Другой вопрос, что я не совсем с вами согласен. Проблема LISP всё-таки в ориентации на функциональное программирование. Это не техническая проблема, а снова - иного характера.
Приходится чуток вывернуть мозги по-иному, чтобы на нём писать, это выворачивание - безусловно полезно, но не нравится тем, кому мозги напрягать не хочется.
Как-то так
Есть чудесная стать про «программистов на LISP» — https://www.marktarver.com/bipolar.html
Она примерно про то, как отчуждение их перемалывает.
Статья действительно отличная, только вот перемалывает их не отчуждение, на мой взгляд, а сочетание особенностей характера с неумением с этими особенностями жить.
У меня тоже такая вот биполярочка, и мне тоже бывает невыносимо скучно порой заниматься тем, что от меня хочет работодатель, и я даже брал от этого рутинного строительства очередного шестого по счету секуребута годовой неоплачиваемый отпуск, чтобы справиться с этой скукой, депрессией, демотивацией от бессмысленности сущего, и прочим подобным. Года вполне хватило, чтобы отрефлексировать и пояснить самому себе, зачем оно, вот это все, и почему устроено именно так.
Корпорация отчуждает результаты твоего труда сразу и в полном объеме, потому что именно за этот труд и его результаты корпорасты деньги и платят. Русское выражение "заработная плата", т.е. "плата за работу" проигрывает в выразительном смысле английскому compensation. Работодатель буквально компенсирует деньгами, страховками, фитнес-центрами, и прочим остальным тот факт, что теперь он - обладатель прав на результаты твоего труда, твои идеи, твой код, твои действия и бездействия. И ты их добровольно передал в результате относительно честной сделки (насколько она может быть честной при большой разнице возможностей, понятно), от которой выгоду получают оба ее участника - корпорация монетизирует твои идеи, код и т.п., а ты при этом освобождаешься от необходимости заниматься этой монетизацией самостоятельно.
Более того, иногда мотивы у корпорации могут быть совершенно отличными от банального "вон чувак умеет программировать, давайте купим его время и мозги, чтобы он нам напрограммировал всякого". Там может быть и "давайте наймем чувака раньше конкурентов, чтобы он им не принес никакой пользы", "давайте наймем чувака, чтобы он перестал нас шельмовать в медиа за косяки, которые он нашел, а мы не исправляем", и т.п.
У меня тут вокруг заметное количество очень сильных, иногда буквально гениальных людей, и почти десяток лет работы с ними научили меня всякому, в том числе тому, что процессы, правила, линтеры и запреты на использование языковых конструкций, которые слишком часто используются неверно даже гениальными людьми, потому что они в первую очередь все таки люди - они не просто необходимы, они неизбежны, также, как и разделение труда и специализаций. Нет, никто не предлагает делить до такой степени, что левую резьбу крутит инженер-леворезьбовик, а правую - инженер-праворезьбовик, но вы буквально упретесь в когнитивные возможности человеческого мозга "понимать все" и "видеть всю картину" уже на уровне RTL, не имея еще никакого ПО вообще.
Настоящего "фуллстека" буквально не бывает, потому что сложность у современных вычислительных систем - абсолютно запредельная, глубокоуважаемый @YuriPanchul не даст соврать. Поэтому договариваемся на берегу про словарь и умолчания, делим обязанности, и жрем этого слона по частям, больше никак.
В Форте то же самое. Это кровный брат Лиспа.
Не знаю как в Яндексе, а на моем текущем месте работы (один крупный банк в желтых тонах) идею сделать что-то за неделю вместо 2 лет и получить результат приняли бы на ура. Хотя у нас тут микросервисы во все поля.
Может быть, кому-то будет интересным, но в начале 20 века, творил поистине великий философ и учёный - А.Богданов. Он, в частности, предложил ввести понятие "фулстек-учёного" и добавить науку, объединяющую все прочие.
...
Основная идея Тектологии состоит в том, чтобы выявлять общие закономерности в совершенно разных науках: общественных и естественных, химии и истории итп, сводя подходы к единообразным...
Эта наука давным давно существует. Называется она философия. Причем в полном виде она была открыта тем же Марксом, на которого вы так любезно ссылаетесь.
P.S: Понимаю, что у позитивистов и некоторых другиих существует свое мнение, но из контекста очевидо, что их подходами я не могу согласиться.
сам Богданов противопоставлял философию и тектологию
Говорил, что занимается не философией... Но при этом взял и по сути переименовал основные философские категории на свой лад, назвав это всё тектологией. Ну и приправил доброй порцией позитивизма. То есть пошел в бок от магистральной линии философии, став просто очередным "некласическим философом".
Зачем нужна такая теория, когда уже придумали диамат (который и скрывается у меня в тексте под именем "наука философия")?
Философия — это что угодно, но не наука.
Вот что получается, если писать статьи в 05:56..
Честно сказать, не пойму реально ли стеб или автор серьезно, поэтому буду отвечать как на серьезную статью.
Софт - он разный. Требуемые характеристики как к готовой программе, так и к процессу разработки всегда будут варьироваться. Естественно нельзя равнозначно рассматривать какой-то скрипт-счетчик на веб сайте и программу управляющую турбинами на АЭС.
Но все-таки, есть тенденция, что мы больше взаимодействуем и работаем вместе. Появляется больше крупных компаний с большими командами, больше open-source проектов, много сторонних зависимостей. В таких условиях становится важнее вырабатывать способы взаимодействия и технологии, упрощающие чтение и понимание кода, его рефакторинг, снижающие вероятность поломок при апгрейде и т.д.
Про миросервисы
Вы считаете, что микросервисы навязывает бизнес, чтобы разработчики не знали всей кухни. А может быть сами разработчики не хотят её знать? Как вы себе представляете онбоардинг нового разработчика в Яндекс, которому нужно разобраться во всём написанном тысячами людей в течение многих лет? Когда такой сотрудник начнет работать, после всего лишь пары лет введения в курс дел?
С организационной стороны они позволяют командам работать намного быстрее. Да, винтики, но так и должно быть в крупных компаниях.
А технически микросервисы распределяют нагрузку. Для них не нужен мега-сервер с ТБ оперативной памяти и сотнями ядер. В добавок можно отрегулировать сколько ресурсов выделять на тот или иной сервис, на сколько его параллелить. Падение микросервиса может сломать лишь часть приложения, а упавший монолит - полный даунтайм всего.
Да, у них много накладных расходов, но в крупных компаниях они оправданы.
Про типизацию
Автор когда-нибудь пробовал разобраться в большом объеме JS кода? Когда пытаешься понять что делает эта функция foo, у которой на входе нечто и на выходе нечто, а в своем коде она вызывает другие такие же функции, работающие с нечто.
Или обновить зависимость в python проекте, вносящую breaking change. Когда баги после такого обновления продолжают всплывать спустя месяц.
Всё это митигируется статической типизацией.
Про goto
Человеческий мозг способен воспринимать одновременно лишь ограниченный контекст. Поэтому мы придумали вначале разбивать программы на процедуры, потом на классы, потом появилось функциональное программирование с чистыми функциями. Всё для того, чтобы можно было посмотреть на кусок кода и понять, что он делает, без необходимости внимательно изучать остальной код. И это действительно работает.
Оператор goto нарушает этот принцип, он заставляет читающего код человека разбираться во всем окружающем коде, куда этот goto переходит, скрывая вместе с этим семантику: то ли это цикл делается, то ли быстрый переход к освобождению ресурсов - на месте не понятно.
Помимо читаемости есть технические аспекты, освобождения ресурсов, валидации возвращаемого функцией типа и тд.
Wrapping up
Получился длинный коммент..
Вообщем, я надеюсь, что все-таки это был стёб (пусть я тогда и напрасно писал всё это).
Но если нет, то, как говорила одна личность: "УЧИТЬСЯ, УЧИТЬСЯ И ЕЩЕ РАЗ УЧИТЬСЯ.."
Вы считаете, что микросервисы навязывает бизнес, чтобы разработчики не
знали всей кухни. А может быть сами разработчики не хотят её знать?
оба тезиса верны. Второй - потому что среднему человеку проще плыть по течению. Увы.
Как вы себе представляете онбоардинг нового разработчика в Яндекс,
которому нужно разобраться во всём написанном тысячами людей в течение
многих лет?
как-то справлялись с онбордингом до этого?
при этом больше задач решали меньшим числом людей
По преждему считаю, что на любой крупный проект достаточно 5 человек (мнение Брукса).
по мере роста проекта из него можно подвыделить второй крупный и получить команду 10 человек.
как-то так
Автор когда-нибудь пробовал разобраться в большом объеме JS кода?
Да и в статье я указал, что об этом (возможно) ещё напишу.
Если коротко: тайпскрипт принёс в JS не только типы, но и модифицированный ООП, асинхронщину итп. Да, что-то обратно вмержено уже в сам JS, но на момент создания тайпскрипт всего этого в JS не было. И тайпскрипт стал популярен не по причине типов (среднестатистический проггер на тайпскрипт, тайпы в нём и не использует), а по причине прочих фич
Человеческий мозг способен воспринимать одновременно лишь ограниченный контекст.
согласен, и потому считаю выпил goto вредным: это приводит к большей многословности (или вложенности) кода, там где с goto могла быть лакончиная программа парсера или стейтмашины
Не по причине типов а по причине наличия декораторов, позволяющих легче завернуть код внутрь фремворков типа ректакта с ангулятором. Типы не пользуют но линтеры для типобезопасности — да. И да, современным кодерам тяжко без линтеров. Как без няньки же.
согласен, и потому считаю выпил goto вредным: это приводит к большей многословности (или вложенности) кода, там где с goto могла быть лакончиная программа парсера или стейтмашины
Кмк, вы слишком категоричны тут, коллега. Нам не нужен один язык на всех. Наоборот, вы же сами пропагандируете универсальность программистов, а значит равное владение разными языками. А в разных областях применения должны использоваться разные языки.
Я, как энтузиаст FP, очень люблю статическую типизацию и вывод типов (она позволяет находить логические ошибки прямо глядя на код вот тут сразу — это автоматизация, освобождающая простор для творчества). Однако, я прекрасно понимаю, что в ряде задач эта автоматизация сковывает полёт мысли. То есть, в ряде задач нужно использовать не Питон, а совершенно безбашенный Lisp со вложенными квазицитированиями (см. мою последнюю публикацию).
Вот та чудесная статья про две культры Плахова (он, конечно С++ник, но в жж он вращался среди функциональщиков тоже) — кмк, реально нужно иметь не две культуры, а спектр. Творчество же разделяется на поиск, фильтрацию и передачу полезного в Культуру. На фазе поиска желательно иметь полёт мысли, на фазе фильтрации-проверки наоборот, желательно сковать себя максимально, чтобы остались лишь верные мысли.
(среднестатистический проггер на тайпскрипт, тайпы в нём и не использует)
Использует, почему же. Надо же явно написать any там, где компилятор за тебя уже вывел что-то более ограничивающее.
На самом деле существует очевидный способ сделать код с goto сравнительно легко читаемым и даже подружить его с линтерами всех мастей. Достаточно в ЯП проапгрейдить goto - а именно, сделать его с индексом, что-нибудь, вроде goto(строка, куда нужно перейти, сгенерированный индекс) и добавить оператор-ловушку, например, назовем его gofrom(строка откуда совершен переход, тот же самый индекс), единственная функция которого - показать, что в это место кода кто-то сделал goto откуда-то именно. И можно даже добавить в IDE средства для автоматического расставления ловушек в места, куда вы сами сделали goto. И все - любые линтеры и IDE смогут это обработать и сделать легко читаемые переходы и даже клики для линков туда-сюда. Внимание, идея зарегистрирована, как торговая марка @goto-gofrom!🤣
Для этого достаточно не использовать одну и ту же метку в нескольких операторах goto.
В статье в этом месте фактическая ошибка — Дейкстра боролся с неограниченным goto, то есть, возможности прыгать куда угодно по тексту программы. Этот goto выпилили, потому, что если вы настолько понимаете, что происходит, пишите на ассемблере. Это даже в С будет дичайшим образом ломать ООО в процессоре и оптимизации компилятора.
Да, основной цикл интерпретатора, видимо, надо писать на ассемблере. Или ассемблеро-подобном языке, не на С. Почему — см. статьи В. Казанцева про pigletvm тут и рассказы автора LuaJIT (если надо, могу найти).
Обычные метки С ломают композиционность структурного программирования. В 80е публиковались статьи по структурному программированию, обосновывающие введение конструкций if/while/do while/continue/break с точки зрения достаточности для моделирования goto и композиционности (т.е. того, что их можно вкладывать друг в друга).
Вот все эти мелочи не умаляют главного посыла статьи, с которым я 146% согласен.
фактическая ошибка — Дейкстра боролся с неограниченным goto
но его послание к людям привело к выпилу goto вообще.
именно на его апокриф ссылаясь и его именем этот оператор предавался анафеме.
А так-то, может быть и Иисус Христос тоже "не то имел ввиду", но что есть, то есть :)
Абсолютно верно. Я призываю вас поклониться богине Гиене Ги — чётко разделять определённую мысль, выдвинуту вполне умным авторитетным человеком, и социальное движение, ведущее её к абсурду. Фактически религиозный фанатизм — положительные обратные связи, аналогичные капитализму (это же тоже положительная обратная связь: капитал должен возрастать).
То, что классики подразумевали под рационально устроенным обществом, обществом, построенным не хаотично, а по плану — это общество, в котором социальные механизмы, положительные и отрицательные обратные связи контролируются, моделируются, убираются когда они нужны, и когда нет.
Наша цель — такое общество. При этом все эти хаки вроде Принципа Питера, бюрократия растёт сама собой, и т.д. должны быть переложены на аппарат Теории игр. А уже после их полного учёта можно будет говорить о построении рационального общества.
Соответственно, коллега, нам нужно очень чётко разделять социальный механизм и случайную затравку, запустившую этот механизм. Затравка нас не интересует! Какая разница, какая именно провокация запустила маховик ПМВ?
Ваша идея давно реализована в языке INTERCAL - 1972 год. Оператор COME FROM. Вы чуть опоздали.
и заодно припомнить, "что они сотворили с фронтендом"...
Хотелось бы услышать. Вот уж что точно не радует все эти годы, так это именно фронт. Хотя понятно, что это мнение будет в меньшинстве.
А вообще статья понравилась, во многом солидарен с автором. Начиная от Goto и вплоть до его отсылок к Марксу, пусть последний и не популярен в здешних палестинах.
Ну как это — не популярен? Судя по моей карме (там почти всё за «политику»), примерно половина за, а половина — против.
Маркс не может быть популярен у тех, кто и выигрывает от нынешнего положения вещей. А среди программистов таких полно, особенно, кто на западе живет, а не в России. Их легко узнать по пещерному антикоммунизму и вере в чудотворные способности свободного рынка и демократии.
Вы конечно извините, но Маркс не может быть популярен у тех кто хоть немного в этом разбирается.
И даже если брать современные левые и/или социальные идеи и движения, то с Марксом они имеют относительно мало общего.
То есть я например даже будучи программистом вполне себе поддерживаю социально-солидарную политику в Германии. Хотя для меня это означает что я плачу больше налогов чем мог бы. Но при этом идеи конкретно Маркса на мой взгляд как минимум устарели. А по хорошему никогда особо хорошими и не были...
С мировым пролетариатом вы тоже делитесь доходами? Ну там разными китайцами на потогонках, с неграми, добывающими редкие металлы.
Во первых да, делюсь. Хотя и не в тех же объёмах.
Кроме того я что-то не припомню чтобы Маркс требовал чтобы одни пролетарии обязательно делились своими доходами с другими пролетариями. Этот аспект его не особо интересовал/волновал.
С чего вы решили, что вы глобальный пролетарий? Вы живете в ядре мир-системы.
По определению слова "пролетарий", которое кстати использовал и даже пожалуй этаблировал сам Маркс :
Пролетариа́т — социальный класс, для которого работа по найму (продажа собственной рабочей силы) является по существу единственным источником средств к существованию.
И это как раз показывает почему идеи Маркса сейчас не особо актуальны. То есть он не особо заморачивался такими вещами как например "расслоение" внутри самого пролетариата.
Так у Маркса же были плохие идеи, которые к тому же еще и устарели. Что же вы ссылаетесь на него, оправдывая свое нежелание делиться?
Я не ссылаюсь на него. Я вам указываю почему идеи Маркса в современном мире уже не особо актуальны. И почему само по себе деление на пролетариев и не пролетариев сейчас не особо имеет смысл проводить.
Вот просто интересно: а лично Вы делитесь своим доходом с пролетариатом? Т.е. стоите возле проходной условного завода и зарплатой делитесь, отлистывая каждому выходящему по купюре? Или как это выглядит? Или должно выглядеть, в Вашем понимании?
А кто это такой вообще: "мировой пролетариат"?
Пролетариат - это класс, лишенный средств производства. В эпоху глобализации и пролетариат стал глобальным. Именно он и имеется в виду.
У молотобойца средство производства - его кувалда. Не вижу причин, почему бы ему не заработать на собственную личную кувалду и перестать быть пролетарием.
Я уже молчу про всяких реперов или актёров, у которых средство производства неотделимо от их организма, и они зарабатывают так, как не у всякого буржуя получится.
У молотобойца средство производства — его кувалда. Не вижу причин, почему бы ему не заработать на собственную личную кувалду и перестать быть пролетарием.Многие так и пытаются делать. Но за ИП-молотобойца работающего на фулл-тайм у одного кузнеца налоговая возмёт это самого кузнеца за попу за уход от уплаты налогов.
Ну а в общем, ИП-молотобоец проигрывает конкуренцию джамшуту-мотобойцу-пролетарию, даже если за него платить надо больше. Просто потому что пролетарий более зависим и потому более «надёжен» для бизнеса. ИПшника обматеришь (или не оплтишь работу) — уйдёт к более вежливому. А пролетарий никуда не денется.
Я уже молчу про всяких реперов или актёров, у которых средство производства неотделимо от их организма, и они зарабатывают так, как не у всякого буржуя получится.Их средство производства не рот и руки, а концертные залы, студии звукозаписи, заводы по производству записей, и сервера со стримминговыми сервисами. Это даёт прибыль, а не раскрывание рта. И это всё принадлежит «лейблам». А музыканты, даже, казалось бы богатые, жалуются, что они нищие. И формально это действительно так. Наслаждаться жизнью они могут тока пока «лейблу» нравятся.
Есть множество исключений, вроде автора музыки к новым DOOM — но у него не только руки, но много дорогущих инструментов, своя студия и несколько наёмных помошников. Т.е. это только подтверждает правило.
Просто потому что пролетарий более зависим и потому более «надёжен» для бизнеса.
Крепостное право вроде отменили? Что мешает офисному пролетарию уволиться и наняться на другую галеру?
Капитализм, который представлял себе Маркс, и существующие реализации капитализма - они достаточно отличаются. Продолжать развешивать ярлыки, потому что так завещал отец-основатель - не особо осмысленно. Мы же не пользуемся для расчета орбит небесных тел эпициклами из геоцентрической солнечной системы, есть и более точные способы.
А про налоги с Марксом не стоит консультироваться , в его капитализме они несущественны.
Это даёт прибыль, а не раскрывание рта.
Раскрывание рта - продукт, совершенно не зависимый от "лейбла". Эти же песни этим же ртом можно петь и на городской площади, и даже что-то заработать. В средние века так делали, нормально было;) Просто сам музыкант на площади может продать свое произведение 100 слушателям, а через посредника - 100 000 000. Хотя, в 21 веке с его интернетами всё не так однозначно.
по сути — отличий нет
то о чём писали Карл Маркс, Ленин, Лондон итп — всё то же самое продолжает иметь место
в чём причины начинающейся новой мировой войны? разве они новые по отношению к 1914-му году? нет
Крепостное право вроде отменили?… а оно в окно ...
Что мешает офисному пролетарию уволиться и наняться на другую галеру?очередь безработных соискателей на улице. Многие из которых готовы работать и за меньшую зарплату и терпеть больше издевательств.
Просто сам музыкант на площади может продать свое произведение 100 слушателям, а через посредника — 100 000 000. Хотя, в 21 веке с его интернетами всё не так однозначно.Всё так же однозначно. Даже ещё однозначнее. Без «раскрутки» «лейблом» артист никак не сможет выделиться из многих десятков тысяч абсолютно аналогичных. Можно, конечно, «раскручивать» себя вроде как самостоятельно — но на это надо уже иметь существенный запас капитала. Это те самые «исключения» о которых я писал.
Я так понимаю, что молотобоец просто машет кувалдой в воздухе, а актеры вещают в чистом поле. Ну тогда ладно.
Ясно. Т.е. если у меня служебный лаптоп - я пролетариат?
Но это дикое, до потери смысла, упрощение. Средство производства — это капитал враженный как в материальных ценностях (лаптоп, оффис), так и в нематериальных: оборотные средства, договора, репутация и т.п.
И да:
В эпоху глобализации и пролетариат стал глобальным
Не стал глобальным, а глобализовался. Это разные вещи! Это разделение труда стало глобальным: т.е. у нас на Земле появились страны-буржуи и страны-пролетарии.
Ок. Почему я, являясь пролетариатом, должен с кем-то делиться? Пусть со мной делятся.
Хм, а почему по вашему вообще кто-то должен делиться? И если такая причина есть, то почему пролетариат должен быть исключением?
Ок. Почему я, являясь пролетариатом, должен с кем-то делиться?
Из пролетарской солидарности. Чтобы класс пролетариев суммарно стал сильнее. И у вас прибавилось прав и благ.
Если более серьёзно — то тупое предавание деньги друг другу на проходной естественно ни к чему не приведёт. Должна быть разумная сила, которая направит денежный поток туда, где он принесёт больше эффекта. Такой силой на локальном уровне должен быть по идее профсоюз. На глобальном — пролетарские партии и их международные объединения (коминтерн)
Т.е. делится с другими пролетариями — это платить профсоюзные и партийные членские взносы.
А отдельные пролетарии — это не пролетариат. Так же как отдельные солдаты — это не армия.
платить профсоюзные и партийные членские взносы
А паритийные и профсоюзные боссы, которые представляют пролетариат - они пролетарии? Если да - почему при галстуке и без кувалды?
Но практика показывает, что как-то не очень плучается :)
Но не лучшего, а хотя бы просто иного другого работающего способа борьбы за свои права (неважно — пролетариат или ещё какая группа) пока не придумали. С организацией может бороться/договариваться только другая организация. А толпа одиночек бессильна. Се ля ви!
Чтоб это реально работало пролетариат должен постоянно ощущать угрозу себе. Т.е. попросту боятся умереть от голода и/или холода. А сидя на диванчике с ноутбуком и чашкой мате — конечно не особо хочется бороться за что-то (кроме качества кода!)
Они политики.
Нувот, кроме буржуев и рабочих, оказывется, политики тоже необходимы.
Это отдельнаяя прослойка (не класс).
И в чем разница между прослойкой и классом? Если подойти к классификации строго, то пролетариями окажутся только те, что стоят у конвеера. А каждый, кто смог себе купить кувалду (лопату, перфоратор, грузовик) - уже предприниматель. Но со времен Маркса мир изменился, и таких вот предпринимателей не меньше чем пролетариев.
И в чем разница между прослойкой и классом?Класс — это классификация групп людей по их отношению к средствам производства (в основном владеют/используют). Но, довольно очевидно, есть множество людей напрямую не задействованных в производственном труде (или оказании услуг): священики, пенсионеры, учащиеся, военные и т.д. — они образуют прослойки (честно — могу врать с термином, давно читал) — т.е. внеклассовые группы, которые однако в один котёл сваливать неразумно — их тоже надо квалифицировать.
Если подойти к классификации строго, то пролетариями окажутся только те, что стоят у конвеера.Не совсем так. Блага цивилизации можно производить и моделируя бороды в барбершопе. Но в общем да, строго говоря пролетариев в современном российском/западном обществе меньше, чем кажется на первый взгляд — спасибо развитию технологий, значительно повысевшему производительность труда во многих сферах. Но их всё равно много: больше чем капиталистов и деклассированных по отдельности.
А каждый, кто смог себе купить кувалду (лопату, перфоратор, грузовик) — уже предприниматель.А вот тут вы сильно не точны. предпринематель — это не тот кто купил себе интрумент, а кто вложился в кувалду (лопату, перфоратор, грузовик), чтобы зарабатывать на этом деньги. Т.е. наличие дрели у меня дома не делает меня предпринимателем — для меня это чисто консьюмерская вешь.
Но со времен Маркса мир изменился, и таких вот предпринимателей не меньше чем пролетариевОн несомненно изменился. Но вы похоже забываете, что текущим пролетариатом являются без преувеличения миллиарды китайцев/индусов/негров на всяких фермах, рудниках и вынесенных в третий мир заводах. А вот «препринимателей» суммарно хорошо если на пару сот миллионов наберётся.
Получение денег просто за то, что ты пролетарий приводит к отсутствию мотивации к труду у этого пролетария.
Маркс не может быть популярен у тех, кто и выигрывает от нынешнего положения вещей.
Это предложение очевидно разбивается об ОПа, который имеет зарплату в разы выше средней в стране и как раз выигрывает от текущего положения вещей.
Бедный человек - борется с линтерами, форматировщиками кода, и прочее.
Интересно что же с ним произошло в момент, когда он узнал о существовании автоматической сборки мусора в виртуальных машинах dotnet, Java etc - Да как же. Это. Возможно! Человеку больше не надо геммороиться с учетом delete на каждый new и прочими утечками памяти? НЕМОЖНО ТАК!
Я разделяю волнения по поводу того что все свихнулись по микросервисам и предают анафеме goto, но зачем впадать в ТАКИЕ крайности?
2@All:
Заметьте, в комментах много споров на тему исключений, goto, а вот с де-факто утилизированным принципом KISS все получается согласны?
Вы в качестве примера привели одну единственную компанию, которая тупо обросла бюрократическим жиром. Это какбы стандартная проблема роста, которая конкретно к программированию имеет отношение очень опосредованное: люди пытаются управлять сложностью, вводя избыточные регламенты.
Экстраполировать один пример на всю индустрию - ну так себе.
146%. Но вот в возражении WraithOW рядом — про бюрократизацию, есть доля истины: отчуждение труда идёт рука об руку с иерархией менеджеров, с КПИ, совершенно несвязанными с целью деятельности, с конкуренцией. Вот эту системную связь было бы неплохо разобрать.
Мне не понятно, почему автор не рассмотрел проблему начиная с 50-х годов, когда начали появляться первые языки высокого уровня? Не упомянул попытки создать эффективные метакомпиляторы в 60-70 (спойлер: они провалились из-за лавиообразного роста сложности обсчета возможных ветвлений в программе)? Почему автор не раскрыл сути отношений между всеми участниками разработки, которые и приводят к тому выгоднее иметь армию средненьких разрабов, чем десяток ученых с тем же метакомпилятором (который остался между мечтами и яблонях на Марсе и коммунизмом к 80-му году из-за проблем, описанных выше)? Почему "правильные цитаты" - это просто цитаты, сдобренные ярлыками, рваным повествованием и историей на подобие притчи. И уже заданные вопросы по сути своей повторяют то, что авторы цитат вкладывали в свои работы без необходимости ярко выставлять их напоказ, рассчитывая на эпотаж публики. Вот это получилось на все 100%, спорить не буду.
Поэтому я не соглашусь с теми немногими из комментаторов, кто пытается подержать автора, мол, как же хорошо, что он привел "правильные цитаты". Только проблема-то в том, что цитаты не канают, когда прямо тут же автор их неявно и опровергает выбранным методом рассуждения.
В части касающейся программистов положения статьи доказаны комментариями блистательно.
О двух причинах, страстям по взаимозаменяемости и привязке к выданному рабочему месту, навязчиво думалось при чтении статьи по соседству, о двух культурах в программировании. Вот и ещё подтверждение - то были два лица одной культуры, капитал-корпоративной.
Не вчера оно началось. Привязка любыми подлостями к серверу - прокатило, тревожно смотреть что на репозитарии Линукс что на хранилища типа crates.io, pub.dev, да и github.com - отключается и цензурируется в пол пинка. Прямые запреты - прокатило, на залоченные загрузчики, эксклюзивные магазины, W^X политику даже бухтеть перестают. Прямое оболванивание - прокатило, один Тик Ток чего стоит.
И дальше (и вообще) всё идёт (и будет идти) по плану. Ибо новые бараны рождаются каждый год, а пастухи меряют историю тысячелетиями. Как позитив - Borland же кому-то в тридорога продаёт и C++ таки развивается. Как негатив - учёные тлейлаксу тоже всегда досыпали позитива до теоретической возможности выживания.
Как позитив - Borland же кому-то в тридорога продаёт и C++ таки развивается
Не знаю-не знаю. Вот Sun продался кому-то "в тридорога" и что получилось? Мир де-факто потерял операционную систему от Sun. Навсегда. Со всеми наработками и достижениями.
"В части касающейся программистов положения статьи доказаны комментариями блистательно."
Читаю комментарии ровно с той же мыслью! Все в шорах своих технологий, спорят про goto и микросервисы, а сути данного произведения не видят(
Как написал автор: «Фрагментарность мышления выражается в склонности программиста зацикливаться на частностях или мелочах, не глядя на картину в целом.»
Какая там суть. Люди просто триггерятся на отдельные слова, даже не дочитывая до конца.
Хотите пример? Смотрите, что дальше будет.
"В СССР не все было плохо".
Очевидная истина, зачем её здесь высказывать-то?
Утверждение правдиво. Там и в самом деле было не все плохо. Но, если меня попросят помочь восстановить все как было в СССР, то, пожалуй, пошлю этого человека в далёкое пешее
Все социальные системы не имеют обратного хода и восстановить их после распада уже невозможно в принципе. Кроме того, я не знаю ни одной политической силы, включая КПРФ, желающей восстановления СССР.
Но при этом в определенных кругах наблюдается нервный и ничем реально не обоснованный страх этого самого восстановления.
Мне кажется, что в такой странной форме люди просто выражают свои опасения, что мир в нынешней его форме подходит к концу. Понятно, что не хочется терять привилегированное положение в нем (а о привилегированном речь, поскольку восстановления СССР боятся отнюдь не пролетарии).
А вообще спасибо за статью. Я, конечно, по-прежнему не согласен. Но, кажется, теперь понял, почему почти во все языки добавили ООП. В C добавили (получился C++), в Pascal и даже в Caml (получился Ocaml). Потому что ООП - это способ писать большим коллективом взаимозаменяемых программистов, то же, что микросервисы, но на другом уровне. Ну то есть я это и раньше понимал, а теперь окончательно осознал. Наличие ООП в языке - это своего рода печать "Данный язык можно использовать в бизнесе". Все побежали эту печать получать
И мейнстримные фреймворки - тоже для этого же. Можно и свой фреймворк иметь и самому развивать (хотя зачем? но это другой вопрос). Но фреймворк - это, условно пусть 50% всего проекта. И если приходит программист знающий популярный фреймворк - он уже на 50% знает ваш проект. А если у вас свой велосипед, то каждый новый программист должен еще и его учить.
Посыл статьи понял как негодование покушением на собственную незаменимость. К дискуссии по сути она не располагает, потому что вы сходу ставите диагнозы.
Есть масса претензий к техническим деталям (динамика-статика, goto, которые у Дейкстры были longjmp, а не Cшные), но это совершенные мелочи. Основная идея подмечена хорошо. Спасибо.
Автор накидал разных проблем и сделал из них вывод, о том, что надо объединяться и заканчивать с господством капитала.
Вывод правильный, но проблемы собраны произвольно и никак друг с другом не связаны. Сравнение внедрения микросервисов с отчуждением результатов труда рабочих не выдерживает никакой критики. Как будто результаты труда разработчиков монолитов не отчуждаются. Ссылаться в одной статье и на Ленина и на Богданова, тоже так себе идея.
по проблемам:
goto. Дийкстра был против широкого упротребления goto людьми, которые не понимают, что это за собой несёт. Короче, goto не для джунов. Взрослым можно.
исключения. Разработчики насмотрелись на плохо сделанную обработку исключений в больших проектах и решили, что проблема в самих исключениях (по аналогии с предыдущей ситуацией). История покажет, были ли они правы. Кстати, обработка ошибок в русте макросом "?", с точки зрения кода, мало отличается от джавовских checked исключений.
фрагментарное сознание. Скорее всего ничего не поменялось, просто мы получили возможность заглянуть в содержимое голов массы соучастников
история из Яндекс.Такси — обычный "кровавый энтерпрайз". Управлять большой массой людей без стандартизации невозможно. При коммунизме стандартов будет ещё больше. И среди них тоже будут чрезмерно универсальные
Вернее всё-таки сказать, что "?" в Rust не макрос, а оператор
Ссылаться в одной статье и на Ленина и на Богданова, тоже так себе идея.
эм? а что тут не так? если бы я ссылался на Троцкого и Ленина, то да, это было бы так себе.
но Богданов ЕМНИП Ленину не противопоставлялся
Богданов — субъективный идеалист. Ильич вскрыл его сущность в известной работе "Материализм и эмпириокритицизм". Конкретно Тектологию не читал, но идея "добавить науку объединяющую все прочие" звучит крайне сомнительной.
Эм… ну и Маркс с Гегелем как бы тоже спорили: "Бытие определяет сознание" (Маркс) — как по мне — радикально ошибочная теория. То есть она работает да, но только в областях приграничных к небытию. И Маркс о них же и пишет: бытие формирует человека с малолетства попавшего в определённые условия, итп.
Здесь он прав.
Однако если отойти от границы с небытием, то очень часто берёт верх Гегелевское "Бытие определяется сознанием". В эту кучу сыпем все примеры от самопожертвований, вроде Матросова, Гастелло, до многих политических решений/выборов в том числе очевидно вредных с точки зрения того самого бытия.
если всё сводить к курице или яйцу — "что первично, бытие или сознание?", то тут Маркс и Ленин очевидно будут правы: природа существовала до появления сознания и независимо от него (Ленин по той ссылке, что вы привели).
если же двигаться к диалектике, которая учит нас рассматривать явление в динамике, то и постулаты Гегеля будут вполне работать на материалистическом поле.
впрочем я куда-то в сторону сбился.
Ленин спорил по философским вопросам со многими, вот, в частности, с Гегелем. Что с того? Гегель от этого стал менее велик? Его не нужно больше изучать?
Если же вернуться к Богданову, то по ссылке Ильич не "вскрыл его сущность", а всего лишь имел с ним спор по условно одному из десятков прорабатываемых Богдановым вопросов. Спор о материалистических/идеалистических основах мироздания ну никак не мешал им обоим понимать одинаково смысл разделения труда, необходимость преодоления эксплуатации человека человеком итп.
как-то так.
Ленин спорил по философским вопросам со многими, вот, в частности, с Гегелем. Что с того? Гегель от этого стал менее велик? Его не нужно больше изучать?
Просто если вы идеалист, то странно апеллировать к материалистам Марксу и Ленину и их строго материалистическим теориям. Если же вы, напротив, материалист, марксист и ленинист, то ссылка на "эмпериомонадиста" Богданова выглядит нелепо.
Просто если вы идеалист, то странно апеллировать к материалистам Марксу и Ленину и их строго материалистическим теориям. Если же вы, напротив, материалист, марксист и ленинист, то ссылка на "эмпериомонадиста" Богданова выглядит нелепо.
проблема оператора goto — в том, что его противники всё абсолютизируют и золотой середины не признают.
"Если goto запихать в каждую строку кода, то получится фигня!" — говорят они, и делают вывод: "goto не нужен!"
Ровно тот же подход предлагаете и вы сейчас. Вы предлагаете ни в коем случае не рассматривать достижения различных философских систем.
А между тем это радикально невзаимозаменяемые множества.
Вот взять Маркса, он сформулировал термин "отчуждение" и предложил варианты (или нарисовал родмап) как это можно преодолеть. Маркс — материалист? Да, до мозга костей.
Но попробуйте ответить на вопрос: ЗАЧЕМ преодолевать отчуждение?
В чём цель?
чтобы человек перестал быть заложником подавляющих внешних факторов (если не ходить по ссылкам дальше википедии)
а что такого в том что он им является?
если вы порефлексируете над этим то неизбежно придёте к тому, что всё упрётся в понятия "хорошо" и "плохо", ну и заодно в понятие справедливости.
плохо — когда человек — винтик, хорошо — когда он творец
плохо — когда человек — раб, хорошо — когда он свободен
несправедливо — когда человек по праву рождения не равен другим, справедливо — когда наоборот
ну и так далее
и вот если мы рассмотрим философские понятия "хорошо" и "плохо", "добро" и "зло", "справедливость" итп, то с удивлением обнаружим, что на протяжении тысяч лет разработкой этих понятий, классификацией, формулировкой занималась… сугубо идеалистические организации, движения — религии.
а материалистическая наука, напротив, дистанцируется от этих понятий. не берёт на себя груз ответственности выдачи и разработки подобных формулировок.
Итого: материализм (по кр мере Марксов) в своём базисе имеет идеалистические целеполагания.
Вывод: рассматривать изолированно материализм и идеализм можно, противопоставлять их нельзя.
Диалектика!
проблема оператора goto — в том, что его противники всё абсолютизируют
Задача инженера состоит в том, чтобы решить проблему лучшим образом наличными средствами. Хорошо то, что помогает решить проблему. По-этому, слепая вера вредит инженеру. К мировоззрению это не имеет никакого отношения
Ровно тот же подход предлагаете и вы сейчас. Вы предлагаете ни в коем случае не рассматривать достижения различных философских систем.
Отнюдь. Но как можно быть одновременно материалистом (= утверждать, что существует материальный мир не зависимый от сознания) и субъективным идеалистом (= утверждать, что мир существует только в сознании субъекта) у меня в голове не укладывается. По-моему, это два взаимно-противоположных взгляда на мир и в систематизированной картине мира ужиться одновременно не могут.
Но попробуйте ответить на вопрос: ЗАЧЕМ преодолевать отчуждение?
Да запросто. Во-первых, потому что это не справедливо (с социалистической точки зрения). Во-вторых, люди работают на себя намного лучше чем на дядю. И если им отдавать плоды их труда, то они будут работать лучше и тогда им придётся работать меньше. Через это у них останется больше свободного времени. Это прогресс. Предвосхищая ваш вопрос, "зачем прогресс?", не знаю, но мир устроен так, что прогрессивное вытесняет регрессивное. По-этому, лучше быть прогрессивным, чем регрессивным.
на протяжении тысяч лет разработкой этих понятий, классификацией, формулировкой занималась… сугубо идеалистические организации, движения — религии.
Любой интеллектуальной работой на протяжении тысяч лет занимались представители религии. Коперник был священником, например. Пастер был католическим фанатиком. Имели ли религии какое-то прогрессивное значение? Да, в древности имели. Должны ли мы тянуть религиозные догмы в 21-ый век? Очевидно, нет. Почему? Потому что объяснение чего бы то ни было на основе мифов четырёхтысячелетней давности сегодня выглядит просто смешно.
несправедливо — когда человек по праву рождения не равен другим, справедливо — когда наоборот
мы с вами выросли в социалистическом интеллектуальном окружении и по-этому этот тезис для нас с вами очевиден. Однако, 1000 лет назад для большинства людей правильным было прямо противоположное утверждение.
а материалистическая наука, напротив, дистанцируется от этих понятий. не берёт на себя груз ответственности выдачи и разработки подобных формулировок.
Потому что это бессмысленное словоблудие. Не бывает абстрактного "хорошо", "плохо" или "справедливо". Есть интересы людей и классов. Когда их интересы соблюдаются — это хорошо и справедливо. Когда нарушаются — плохо.
Итого: материализм в своём базисе имеет идеалистические целеполагания.
Вы их сами только что выдумали, эти "идеалистические целеполагания". У материализма (как впрочем и у идеализма) цель описать мир. Точнее дать базис для такого описания.
ну блин
даже вы же на вопросы отвечаете "потому что это не справедливо", "лучше чем" итп
и при этом же противоречите себе что определять "хорошо" и "справедливо" с точки зрения материализма — "бессмысленное словоблудие".
соответственно либо цели к которым движутся материалисты — словоблудие.
в этом случае они совершенно бессмысленны
либо смычка материального и идеального имеет право на существование и вот я нашёл её у Маркса, не вижу ничего плохого (и Ленин не видел) в том, что она была у Богданова, ну и так далее
даже вы же на вопросы отвечаете "потому что это не справедливо", "лучше чем" итп
Потому что мы с вами существуем в одном и том же инфополе и каждый раз добавлять "с точки зрения рабочего класса" или "для рабочих" или "для прогресса", я нахожу назойливым и скучным. Оно и так понятно.
и при этом же противоречите себе что определять "хорошо" и "справедливо" с точки зрения материализма — "бессмысленное словоблудие".
Определять вообще "хорошо" и "справедливо" бессмысленно. Потому что это относительные понятия. То есть "хорошо" и "справедливо" бывает только для кого-то.
соответственно либо цели к которым движутся материалисты — словоблудие. в этом случае они совершенно бессмысленны
Материалисты никуда не движутся, так как они не являются организацией и не представляют из себя сообщество.
смычка материального и идеального имеет право на существование и вот я нашёл её у Маркса
Вы её додумали у Маркса. "Нашёл", это если бы вы цитату привели.
Потому что мы с вами существуем в одном и том же инфополе и каждый раз добавлять "с точки зрения рабочего класса" или "для рабочих" или "для прогресса", я нахожу назойливым и скучным. Оно и так понятно.
какая разница с точки зрения рабочего класса или прогресса?
мы же о понятиях "хорошо" и "плохо"
если материализм отказывается их формулировать, но формулировки использует, то получается материализм базируется на идеализме. По крайней мере в целеполаганиях, по крайней мере марксистский материализм в той его части, где предполагает решения проблем отчуждения.
Материалисты никуда не движутся, так как они не являются организацией и не представляют из себя сообщество.
я всё время подчёркиваю — что не все материалисты, а та часть, которая про марксизм. и в этом сообщении и в предыдущих.
ЗАЧЕМ преодолевать отчуждение?
ЗАЧЕМ увеличивать (до 100% в идеале) количество творческих личностей?
какая разница с точки зрения рабочего класса или прогресса?
мы же о понятиях "хорошо" и "плохо"
Потому что это относительные понятия. Сами по себе они не имеют смысла. Если не читали, гляньте "Диалоги" Платона. Там Сократ страниц на 500 пытается выяснить, что такое "добродетель" вообще.
я всё время подчёркиваю — что не все материалисты, а та часть, которая про марксизм. и в этом сообщении и в предыдущих.
Марксисты тоже разные бывают. Каждая организация определяет сама для себя куда ей двигаться.
ЗАЧЕМ преодолевать отчуждение?
ЗАЧЕМ увеличивать (до 100% в идеале) количество творческих личностей?
Потому что это прогресс. Предвосхищая ваш вопрос, "зачем прогресс?", не знаю, но мир устроен так, что прогрессивное вытесняет регрессивное. По-этому, лучше быть прогрессивным, чем регрессивным.
Потому что это относительные понятия. Сами по себе они не имеют смысла. Если не читали, гляньте "Диалоги" Платона
а Платон — кто? разве не идеалист? как вы можете апеллировать к идеалисту в материалистических вопросах?
(видите, я тоже могу подобные вопросы задавать :P)
Марксисты тоже разные бывают
и идеализм Богданова не мешал ему быть марксистом, заниматься пролеткультом и прочим
материализм Ленина не мешал ему поддерживать идеалиста Циолковского.
Вы же помните историю, почему Циолковский занялся ракетным движением?
пришёл он как-то в гости к русскому космисту Фёдорову, а тот ему и говорит: в ближайшее будущее мы воскресим всех умерших людей на планете и представляешь что будет? тотальное перенаселение!
Циолковский так впечатлился, что решил заняться способами освоения космического пространства.
а Платон — кто? разве не идеалист? как вы можете апеллировать к идеалисту в материалистических вопросах?
Это не апелляция, а отсылка к примеру бессмысленного словоблудия. Порождённого идеализмом. Но Платона можно простить, он древний.
материализм Ленина не мешал ему поддерживать идеалиста Циолковского.
Вы путаете философскую базу и политическую практику. Если бы у Ленина был принтер для печати идеальных людей, то можете не сомневаться, все его соратники, сотрудники и подчинённые были бы идеальными. Но, в реальной жизни приходится работать с тем кто есть. Политика, как говорится, — это искусство возможного.
Вы путаете философскую базу и политическую практику. Если бы у Ленина был принтер для печати идеальных людей, то можете не сомневаться, все его соратники, сотрудники и подчинённые были бы идеальными. Но, в реальной жизни приходится работать с тем кто есть. Политика, как говорится, — это искусство возможного.
Сталинское: "других писателей у меня для вас НЭТ".
так что, снимаем тезис о некорректной отсылке к Богданову и Тектологии? Ни идеализм Богданова не влияет на "политическую практику" ни отсутствие/присутствие материалистичных альтернатив.
Предвосхищая ваш вопрос, "зачем прогресс?", не знаю
ну вот, чем отвечать на вопросы — фиксируем отказ от их рассмотрения.
я вас не упрекаю, просто констатирую факт
ЗАЧЕМ преодолевать отчуждение?
Смотря кому.
ЗАЧЕМ увеличивать (до 100% в идеале) количество творческих личностей?
Чтобы те, кто не хотят ими быть, вымерли и не мозоли глаза.
И если им отдавать плоды их труда, то они будут работать лучше и тогда им придётся работать меньше.
Допустим, рабочий на сверлильном станке сверлит дырки в деталях. Если результат его работы не очуждать - зачем ему сколько дырок? А другой рабочий вырубает детали с помощью пресса. Если результат его работы не отчуждать - первому рабочему негде будет сверлить дырки.
у Джека Лондона (список литературы выше) есть ответ на этот вопрос, почитайте
Я читал и более современную фантастику. Там расширяться капитализму было уже некуда. Но выход был найден: кредиты. Там люди покупали всё в кредит, с обязательством оплаты ещё неродившимися детьми и внуками. Тоже неплохо. Разрядности компьютера хватит для хранения долговых обязательств.
Капитализм - это способ обеспечения экспоненциального роста экономики с помощью капитала, всего лишь. Экспорт в слаборазвитые страны - это не обязательно капитализм, так и в древнем Риме делали.
Я читал и более современную фантастику. Там расширяться капитализму было уже некуда. Но выход был найден: кредиты. Там люди покупали всё в кредит, с обязательством оплаты ещё неродившимися детьми и внуками
ну да, описания этой самой железной пяты у многих писателей присутствует.
а вот рассмотрения «как её избежать» — почти ни у кого. поэтому классики всё ещё и остаются классиками.
Я читал и более современную фантастику. Там расширяться капитализму было уже некуда. Но выход был найден: кредиты. Там люди покупали всё в кредит, с обязательством оплаты ещё неродившимися детьми и внуками
кстати, вы (ну или те фантасты) тут почти сформулировали религиозное понятие «первородный грех».
а заодно другое, что царь/боярин/ну или вообще власть — наместники бога на земле — поскольку безгрешны
PS: Если почитать современных фантастов, то крайне часто натыкаешься на описание вариаций родо-кланового общества.
почему они не решаются поискать в своих фантазиях более справедливое общественное устройство, как вы думаете? почему классики решались, а они нет?
причём классики решались не только на рассмотрение социализма, но и иных видов общества.
Взять например: «Град обречённый» Стругацких.
Как по мне, так лучше жить в этом граде, нежели в родо-клановом обществе, которое так часто рисуют современные фантасты.
менее тошно что ли, ну и более справедливо
почти сформулировали религиозное понятие «первородный грех».
Ничего удивительного ;) Все сюжеты уже встечались ранее - либо в Библии, либо у Шекспира, либо в ЮжПарке. Так же как все алгоритмы придуманы в 70-80х годах.
Если почитать современных фантастов, то крайне часто натыкаешься на описание вариаций родо-кланового общества
Если дать фантасту машину времени, он загадит своими попаданцами всё до самого мезозоя (ц)
Эскапизм неплохо продается, вот и весь секрет удивительного долголетия ёжиков.
иных видов общества.
Для иных видов общества, подозреваю, нужны более другие виды человеков.
я пытался вас сподвигнуть на рефлексию: почему он неплохо продаётся?
мой ответ таков (я выше озвучивал): что справедливого общества даже в фантастических чаяниях люди не видят.
и это повод для серьёзного уныния, на самом деле
> Для иных видов общества, подозреваю, нужны более другие виды человеков.
человека отличает от животного то, что он может становиться над инстинктами и, соответственно, менять правила игры и меняться сам.
ваш же человек — от животного отличий не имеет, а потому в чём смысл его существования?
справедливого общества даже в фантастических чаяниях люди не видят.
Это называется систематическая ошибка невыжившего. Люди, наблюдавшие как оно выглядит, это справедливое общество - что они должны увидеть?
человека отличает от животного то, что он может становиться над инстинктами и, соответственно, менять правила игры и меняться сам
Да, говорят, что именно затем Моисей водил евреев 40 лет по пустыне. Не уверен, что у него всё получилось.
а ещё помимо фантастики, на тему «расширяться более некуда» у нас есть ещё и история. И даже название тому, что растёт из «расширяться более некуда» — дано звучное — Тёмные века.
Простите, нет сил перечитывать все сотни комментариев, что бы понять, высказывал кто-то похожие мысли или нет
Но не было ли у автора мысли, что история про 50 строк кода - это не история про микросервисы и стандарты, а история про политику и деньги?
В конце концов, сэкономить бизнесу миллиард рублей в месяц ценой 50 строк кода - это достижение одного разработчика. Которое еще и не будет оценено по достоинству (хотя бы из за огромного несоответствия масштаба усилий и выхлопа), а сэкономить миллиард в месяц ценой создания огромной системы с нуля и привлечения нескольких новых команд - заслуга CTO, который потом будет соответствующе награжден и сможет этим везде хвастаться.
Мне кажется, эта история - пример того, что у каждого правила есть недостатки (и тем не менее, достоинства их перекрывают). Допустим кто-то может предложить маааленький патчик, который нам много что даст, и "что тут думать, прыгать надо, давайте уже по быстрому в продакшн!". А злые бюрократы не дают. А патчик в самом деле маленький и безопасный. Но если мы открываем возможность для всего, что "вроде безопасно", то сегодня у нас будет этот патчик, завтра другой, а через пять дней будет тот, который казался безопасным, но что-то непредусмотрели и грохнули весь бизнес.
Надо просто понимать и принимать, что многие правила - не идеальны. В них есть минусы, эти минусы стоят деньги. Но даже в этом неидеальном виде они полезны и их приняли осознавая эти минусы.
Но не было ли у автора мысли, что история про 50 строк кода — это не история про микросервисы и стандарты, а история про политику и деньги?
была, и эта мысль привела к данной статье: о политике и капитале :)
Так уж люди устроены. Например, они тысячелетиями верили, например, что если молиться каждый день и ходить в церковь, это поможет решить в том числе и материальные проблемы.
Теперь целая отрасль верит что определенные вещи эффективны потому что все их применяют а не потому что есть доказательства их эффективности. Микросервисы (когда они становятся действительно "микро") возможно одна из таких легенд.
Но в целом это работает. А главное - это способ победы над безработицей. Когда сложную задачу решает 3 гения, остальным нечего делать. Это дешево не не стабильно. Когда ее же решают опять эти три гения, но которые не имеют право все закодить сами, а вместо этого у них в подчинении 100 не-гениев, это дороже, но стабильнее. И у всех есть работа.
Можно взять, например фреймворк, в котором достаточно добавить поле в один класс и оно сразу будет доступно в браузере без пяти маперов и промежуточных перекладываний. Можно истребить все разнообразные инструменты и оставить один для каждой цели.
Но к счастью или к несчастью, по этому пути мы не идем. Вместо этого в каждом проекте нужно 100 обезьян, которые будут кропотливо изучать документацию по каждому инструменту, который решили использовать, а потом писать кучу кода по перекладыванию данных. Зато этот процесс гибкий, масштабируемый и у всех есть работа...
Воевать с безработицей и создавать "скрытую безработицу" (рабочие места для людей, которые делают пустую работу) - это задача государства. Мало какой капиталист наймет за свои деньги 10 человек там, где справятся 3.
А фреймворки жирнеют по обычной причине - маленький фреймворк идеально подходит для маленького проектика. Но... чего-то в них нет и для другого проекта не подходят. Тогда добавляют одну фичу. Потом другую. Потом фич так много, они конфликтуют, и надо их как-то подключать-отключать. И появляется включалка-отключалка.... Фреймворк становится жирным, в нем дофига всяких ненужных (в простой задаче) плюшечек... И появляется новый лайтовый фреймворк, который идет тем же путем.
Мне в этом плане понравилась философия Svelte: Пусть лучше этот проект любит небольшое количество людей, чем ненавидят все. (Хотя с выходом их SvelteKit, мне кажется, они шагнули слишком уж вширь и простые вещи стали сложными, отступили от принципа).
Аналитики: этонужнобизнесу!
Менеджиент: Боги хотят больше кода! Больше кода для богов!
Инженеры: Нифиганепонял, вот вам копипаста из соседнего проекта.
Реальность: Вы родили очередную метрику формата "килограмм ежа на квадратный метод ужа" на которую всем будет плевать через три недели включая авторов. Кстати она у вас сломана.
...через 6 месяцев
Инженеры: мы не можем сделать эту фичу она поломает метрики. В частности еж-кг/уж-м2.
Бизнес: Чииво? Аналитики!
Аналитики: Это не мой проект, надо месяц на погружение.
Менеджеры: Ломать нельзя! Богам надо больше кода и быстрее!
Инженеры: Три недели.
Бизнес: х..ли все так медленно? Чем вы там вообще занимаетесь?
...через 10 лет
Аналитики: этонужнобизнесу!
Менеджиент: Боги хотят больше кода! Больше кода для богов!
Инженеры: (1) найдите технического хозяина, (2) напишите спецификацию по стандарту, (3) договоритесь о SLO, (4) положите TCO+20% в бюджет, (5) мы напишем микросервис/пайплайн и т.д.
Бизнес: блин это долго, сложно, дорого и нудно. Оно нам вообще надо?
Инженеры: не благодарите!
Яндекс контора немаленькая, в описанной ситуации "надо узнать почему..." вероятно надо было узнать не так уж сильно. Рискну предположить что прямо даже наоборот.
груг очень любит системы типов упрощают программирование. для груга системы типов самая польза когда груг нажимает точку на клавиатуре и магией открывается список что может сделать груг. это 90% пользы от системы типов для груга
addition. груг плачет, когда на экран выпригивает ZeroDivisionError. груг не тестирует пограничные случаи. груг не читает документацию. груг не документирует исключения.
И именно это не дает развиваться языкам в сторону большей абстрактности и выразительности. Зачем, если можно сочинить 100500 методов для объекта и заставить их потом выбирать по точке?
Думаю основными противниками исключений являются разработчики делающие ставку на развитую и явную систему типов. Например, если Вы пишите на Python и используете MyPy для статической проверки типов -- возникает естественный соблазн заменить исключения на возвращаемые ошибки. Тогда Вам не придётся помнить какие исключения могут быть подняты в тех или иных вызовах. Тогда IDE явно будет Вам подсказывать, что функция может вернуть, скажем, целое число или объект типа AttributeNotFound. Хотя, быть может, тут система типов, пытаясь вытеснить из языка исключения, выступает в роли антипаттерна "золотой молоток" (иллюзия универсальности инструмента). Полностью отказаться от исключений и явно обрабатывать ошибки на всём стеке вызовов -- верный способ воссоздать проблему, которую уже решили в 1970-х годах... придумав исключения.
Однако постепенно такие возможности закрываются и далее будут закрываться ещё агрессивнее. По мере роста отчуждения труд разработчиков будет всё сильнее дешеветь, пока из нынешних хипстеров не получатся настоящие пролетарии.
Вот это, если задуматься, очень интересный пассаж в контексте примера с Яндекс.Такси. Потому что так-то источник прибавочной стоимости - это таксист. Он крутит баранку, следит за уровнем омывайки и развлекает пассажиров рассказами о том, чем сам любит заниматься для души. Эту стоимость у него изымает Яндекс и распределяет внутри себя. А автор, будучи сотрудником Яндекса, является по сути, пособником в этом процессе угнетения рабочего класса.
Эксплуататор жалуется на эксплуатацию. Прелестно-с.
Эксплуататор жалуется на эксплуатацию. Прелестно-с.
рабов на плантациях охраняли… рабы.
разве они были эксплуататорами?
Это вы товарищам из ЧК затирать будете.
паяц
Ответов-то по существу ждать, или язык проглотил?
https://habr.com/ru/post/709328/comments/#comment_25109076
https://habr.com/ru/post/709328/comments/#comment_25109108
Разверну мысль, а то до вас же не дойдёт. Вы сознательно выбрали работать в большой компании, которая сыграла наибольшую роль в падении доходов таксистов за последние десять лет. Вы вполне могли отнести своё резюме в небольшой таксопарк, или стать частью таксистской артели, и получать там справедливую зарплату на том же уровне, что и сами таксисты. Вместо этого вы сознательно, ради личной выгоды, отправили своё резюме монополисту.
Вы не раб - у тех не было выбора, что сказали, то и делаешь. Вы человек низких моральных качеств, который не в состоянии нести ответственность за свои поступки в соответствии со своими же убеждениями. Иными словами - "чуждый рабочему классу элемент", которых в последнюю революцию на ура в прорубях топили.
Мы отрицали goto, как могли...
получили for->if->break/continue и switch->case->break
Информация к размышлению... Штирлиц шёл по корридору...
Избыть из себя лакея крайне сложно. Начать думать - ещё сложнее.
А в чём проблема с исключениями? Много слышал, пытался разобраться, но какой то внятной информации, почему исключения это хорошо/плохо не нашёл. При этом почти в любом учебном материале всегда присутствуют способы создания и обработки исключений.
А в чём проблема с исключениями?
управление передается непонятно куда (фактически это тот же goto, только замаскированный) это раз, это весьма медленно (примерно на 3 порядка медленнее чем классическая обработка ошибок) это два, очень часто это неправильно используется (например вместо условной логики для изменения хода программы) это три.
Спасибо. Возможно подскажете ещё с одним вопросом. Я слышал про концепцию об отказе от NULL. Особенно, что нельзя возвращать null из метода. Однако получается, что если в методе возникает некая ошибка, то мы не должны ни null возвращать, ни exception вызывать. И у меня диссонанс по этому поводу.
Ну например можно всегда "заворачивать" ваш результат в какой-то Result с полем success true/false.
А лучше в какой-нибудь Either<Data, Error>
А что делают с stacktrace? Это не призыв поспорить. Реально интересно
Ну вы его по идее точно так же можете "передавать по цепочке" добавляя в Result. Если вам это надо.
stacktrace как таковой не настолько важен, важна, скорее, цепочка контекстов. "Начали делать действие X, внутри него начали делать действие Y, внутри него вылетела ошибка Й" - этого на практике вполне достаточно, если, конечно, не надо копаться в потрохах слишком умного фреймворка.
Есть разные подходы:
Классика Си - коды ошибок, обычно возвращается как результат выполнения функции, а настоящий результат который должна вернуть функция, устанавливается по указателю, на внешние данные, которые эта функция должна инициализировать или установить. Например в 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 установкой некоего значения по умолчанию или кода который вернет нужное значение.
Что-то другое, но на ум пока ничего не приходит
Первая и единственная реальная проблема исключений - скорость. Исключения очень медленные. Настолько, что выгоднее написать проверку условий до вызова или вернуть код ошибки. Слава богу сейчас реализация исключений такова, что дополнительные расходы на исключения минимальны когда они НЕ выбрасываются. Но когда выбрасываются это очень медленно.
Вторая проблема исключений - в подавляющем большинстве случаев их не надо перехватывать, но программисты все равно это делают.
И тут возникает здравая идея: давайте поделим все исключения на те, которые не надо перехватывать (например Usage Exceptions) и те, которые можно перехватывать (IOException, SocketException). Первые пусть приводят к падению программы, а вторые заменим возвратом кода ошибки. Примерно так и подумали в Rust и Go.
Но эта идея хороша только на первый взгляд, так как длинный код из последовательных IO операций с возвратом ошибок становится нечитаемой кашей.
В Rust вроде одумались и собираются ввести автоматическую обработку исключений. Плюс там возврат кода ошибок делается через or-типы, у которых есть методы превращающие перехватываемое исключение в неперехватываемое.
В Go нет таких типов, там функция возвращает два значения, а не одно значение специального типа. И хорошего решения нет.
Монданый синтаксис мог бы помочь в этой ситуации, но его нет ни в Rust, ни Go.
Ну и третья проблема, скорее идеологическая - выбрасывание и перехват исключений это аналог Goto, из-за чего могут не выполниться важные части кода. Но фактически это не проблема, так как нормальные языки научились использовать try\finally и автоматически вызываемый код при выходе из scope.
Первая и единственная реальная проблема исключений — скорость
нет такой проблемы.
исключения совершенно точно не медленнее ручной проверки.
ибо когда вы пишете
result, error = foo()
if error {
return nil, error
}то вы делаете ровно то же, что делал бы компилятор под капотом, если бы распространял исключения вверх по стеку.
Нет
хорошо, перефразирую немножко: вместо "вы делаете ровно тоже что делал бы компилятор", прочитайте "вы делаете то, что может делать компилятор".
я не сомневаюсь что в том или ином движке исключения могут быть реализованы так, сяк или об косяк, и даже не сомневаюсь в том что будут ссылки на это.
однако вот приведённый код (каждый foo возвращает пару "результат-ошибка" и ошибка распространяется return'ами вверх по стеку) является полным эквивалентом исключения и потому может быть реализован компилятором. А значит как минимум НЕ БЫТЬ медленнее ручных манипуляций
ну или перефразируя ещё одним способом: если утверждается, что вот это, написанное человеком — работает быстрее того, что есть в компиляторах, почему не взять это и не вложить в компилятор? Причин, мешающих так сделать, нет, а следовательно высказывание что "проблема исключений — скорость" — ложно
Я вам показал бенчмарк из реального мейнстримного языка программирования. Давайте добавлю бенчмарк исключений в плюсах. Там ровно та же особенность https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/
Вы сделали не то что делается типовыми реализациями исключениеями. И не то что ожидает пользователь. Ваше поведение не реализует типовой контракт декларируемый исключениями со массовых языках. И его нельзя с ними сравнивать.
Я вам показал бенчмарк из реального мейнстримного языка программирования. Давайте добавлю бенчмарк исключений в плюсах
да блин мне всё равно на тот бенчмарк, я ведь о другом говорю. бенчмарк может по какой-то причине быть плохим. я вам говорю что можно сделать компилятор, бенчмарк которого будет минимум не хуже того кода, который лепят Go/Rust программисты в каждой первой функции
да блин мне всё равно на тот бенчмарк, я ведь о другом говорю. бенчмарк может по какой-то причине быть плохим
Вы код бенчмарка смотрели? Покажите что именно там плохо сделано. Или напишите хороший.
можно сделать компилятор, бенчмарк которого будет минимум не хуже того кода, который лепят Go/Rust программисты в каждой первой функции
Покажите пример. Исключение это определенная и довольно тяжелая сущность. Ее сделать стоит дорого. Интересно как ее создание кто-то смог сделать легким.
Вы код бенчмарка смотрели?
нет же.
Покажите пример.
вот же он показан
res, err = foo()
if err {
return nil, err
}берём например ПРЕПРОЦЕССОР, и запихиваем мусор про проверки if err в него.
получаем что на уровне языка пользователь больше не манипулирует err'ами (там где ему не нужно), и пишет просто
res = foo()там где он напишет
try {
} catch (err) {
}препроцессор оформит вызов кода из catch блока вместо простого return.
СОВЕРШЕННО ТОЧНО этот подход не будет медленнее ручных вездесущих вставок if err { return nil, err }
А как препроцессор узнает, какие функции нужно оборачивать в этот блок, а какие нет?
А как вы думаете почему минимум в двух массовых языках так не сделали? То что там языковые конструкции и их реализации придумывают глупые люди можно сразу откинуть.
Слово контракт вам о чем-то говорит? В применении к CS.
Не знаю про go, но про Раст это не так.
Проверять на err значение все вызовы дорого (по CPU). Идеология exception'ов: любая функция может выбросить любой эксепшен, но большинство вызовов err-значения возвращать не будет, поэтому exception'ы можно обрабатывать долго.
Другая альтернатива (выбранная Растом) звучит так: в compile time известно какие функции какие exception'ы может выбрасывать и проверять нужно только такие вызовы (а остальные проверять не нужно).
Знание во время компиляции нужно, например, для колбеков: возьмём тривиальную функцию, которая просто сразу зовёт полученный на вход колбек и больше ничего не делает. В Rust это будут разные функции, в зависимости от того, может ли колбэк бросать исключение или нет (и, в зависимости от этого, сама функция будет либо бросать, либо нет). В итоге если использовать первую функцию, то есть гарантии, что ошибки не будет (и проверять на наличие ошибки не нужно), а если вторую - то возможность ошибки появляется (и это видно по сигнатуре функции).
В какой-нибудь Java такого разделения сделать не получается, в итоге либо нужно все непрямые вызовы проверять на ошибки (что дорого, потому что ошибки случаются редко), либо дополнительно платить за обработку каждого исключения.
поэтому exception'ы можно обрабатывать долго.
поясните почему если код напишет разработчик то это дёшево, а если ТОТ ЖЕ КОД вставит туда препроцессор, то это дорого.
Вставлять такую на каждый вызов каждой функции банально дорого.
Либо нужно вставлять только для тех вызовов, для которых нужно, либо, альтернативно, ни для каких не вставлять.
В первом случае разработчику (или компилятору, если он делает это сам) нужно уметь отличать вызовы, которые могут вызвать эксепшен от тех, которые не могут.
Во втором случае нужен отдельный механизм обработки эксепшенов, который не бесплатный.
Вставлять такую на каждый вызов каждой функции банально дорого.
а зачем вставлять в каждый вызов?
представьте что вы — компилятор.
Вы парсите функцию foo.
На выходе у вас есть ответ на вопросы:
- может ли foo вернуть ошибку: да/нет
- список функций которые вызывает
- у каждой функции которые вызывает признак: возвращает ли ошибку
- у каждой функции которые вызывает кодовый блок обрабатывающий ошибку или его отсутствие
далее глядя на собранную информацию, вы очень легко НЕ вставляете в каждый вызов код там где он не нужен и вставляете там где он нужен
Ну компилятор Rust вон например времена жизни ссылок и владельцев контролирует. При этом владельцы могут через значительный стек присваиваний/вызовов функций передаваться. От чего с такой мелочью, как определение необходимости вставлять/не вставлять блок с ошибками было бы невозможно справиться?
Так Раст и справляется, вроде бы. Просто это является (как и время жизни) частью сигнатуры функции. Если функция возвращает Result<T,E>, то это можно читать как "может вернуть T, а может бросить исключение E". Собственно, пробрасывание E наверх (если ты находишься в функции, которая может вернуть E, или, хотя бы, что-то к чему E приводится) делается одним оператором ("?").
Проблема примерно такая - если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
Проблема примерно такая - если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
А это возможно? Ну то есть например в Java вы просто не сможете пометить функцию как не бросающую исключения если при этом она вызывает какие-то функции помеченные как бросающие. И при этом не обрабатывает эти исключения сама.
Ну то есть например в Java вы просто не сможете пометить функцию как
мы говорим о потенциальном препроцессоре же. а не о конкретном Java. конечно возможно
Ну во первых человек вроде бы писал про конкретный раст.
А во вторых если это возможно, то у вашей идеи появятся огромные проблемы при использовании прекомпилированных библиотек и/или интерфейсов.
Потому что тогда ваш препроцессор не будет знать что там на самом деле происходит или не происходит внутри вызываемой функции.
Ну во первых человек вроде бы писал про конкретный раст
дык и я в статье про конкретный раст. перескок на Java в которой невозможно как раз и пытался отбить.
А во вторых если это возможно, то у вашей идеи появятся огромные проблемы при использовании прекомпилированных библиотек и/или интерфейсов
сигнатуры функций даже прекомпилированных известны?
Result<T,E> — считаем функцией могущей вернуть ошибку и врапаем её в функцию бросающую исключение и всего делов
Result<T,E> — считаем функцией могущей вернуть ошибку и врапаем её в функцию бросающую исключение и всего делов
Хм, вы по моему не поняли о чём речь. А именно вот о таком поведении :
Проблема примерно такая - если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
Проблема примерно такая — если сама функция помечена как "не бросающая эксепшенов", но при этом она вызывает функцию, которая может бросить, какое ожидается поведение?
кем помечена? человеком? плевать на его пометки, их будет расставлять препроцессор
если помечена препроцессором, то это баг препроцессора — его надо исправлять
А как препроцессор может что-то пометить если он не видит сам код? То есть например если используется интерфейс, а конкретная имплементация неизвестна?
А как препроцессор может что-то пометить если он не видит сам код?
а к чему же он ПРЕпроцессор?
То есть например если используется интерфейс, а конкретная имплементация неизвестна?
вот например есть typescript. работает так:
программист пишет на языке с типами
потом компилятор (препроцессор на самом деле) делает б-ж-ж-ж-ж и на выходе получается код преобразованный из typescript в javascript.
можно сделать с растом так же. на входе rust с исключениями, в котором развёрнуты под капот все конструкции Result<T,E> а на выходе обычный rust. как-то так.
Вот например у меня система плагинов. Каждый плагин должен имплементировать интерфейс. Но при этом какой из плагинов будет использован будет известно только после запуска программы. Более того в теории во время работы программы одни плагины могут быть заменены на другие. Плюс отдельные плагины могут быть созданы и после реализа самой программы.
Как в таком сценарии должен работать ваш препроцессор?
вот проект который делает джаваскриптер
у него три файла file1.ts, file2.ts, file3.ts — на тайпскрипте
а ещё два file4.js и file5.js на джаваскрипте
перед запуском всё конвертится в js
точтак и с растом
main.rs — обычный раст
foo.rse — раст с исключениями из которого препроцессор перед компиляцией сгенерит foo.rs — обычный раст, как-то так можно сделать
и для голанг тоже самое
Я всё ещё не вижу ответа на мой вопрос.
То есть смотрите вы скомпилировали программу и отослали её клиенту. А он сам пишет плагины под нужные интерфейсы.
Откуда препроцессор, который вы использовали для создания вашей программы, должен знать что там ваш клиент напихает в свои плагины? Ну то есть откуда ему знать будут в плагинах бросаться какие-то исключения или нет?
Единственный вариант, который я вижу это обязательное указание исключений в сигнатурах интерфейса. Да и то может такое быть что в сигнатуре исключение указано, а на самом деле его не будет.
мы говорим о препроцессоре, сворачивающем Result<T,E>
какая разница плагин там или еще что? достаточно сигнатуры функции
Что в данном случае значит "сигнатура функции"?
Вы вот выше написали:
Кем помечена? человеком? плевать на его пометки, их будет расставлять препроцессор
Сигнатура конкретной имплементация? Так она препроцессору неизвестна потому что ещё не существует.
Сигнатура интерфейса? Так а его разве препроцессор пишет?
Что в данном случае значит "сигнатура функции"?
когда компилятор готовит объекты для рантайм связывания, то он генерирует для каждой функции их сигнатуры.
я возможно термином из другого языка оперирую, в расте я ещё не разбирался как это называется.
сигнатура это нечто, в машиночитаемой форме описывающее
- имя функции
- возвращаемое значение (тип)
- аргументы (количество, типы, иногда — имена)
без знаний этих параметров вы не сможете соединить два разных куска кода друг с другом.
иногда достаточно имён, но в случае с Растом — к гадалке не ходи — будет вся эта инфа
посмотрите nm target/debug/<ваш файл>|grep Result например
Извините, а вы вообще когда-то в своей работе имели дело с интерфейсами? И если да, то можете мне объяснить как препроцессор должен создавать сигнатуры интерфейсов? Или как компилятор должен их генерировать?
Или давайте ещё проще: вот я компилирую у себя кусок кода и мой клиент в то же самое время компилирует у себя кусок кода. Как нам сделать так чтобы потом эти два куска кода можно было "соединить"? Ну то есть чтобы сигнатуры совпали?
Извините, а вы вообще когда-то в своей работе имели дело с интерфейсами? И если да, то можете мне объяснить как препроцессор должен создавать сигнатуры интерфейсов? Или как компилятор должен их генерировать?
как компилятор компилирует вызов функции из другой библиотеки?
допустим пока нет препроцессора.
вот вы написали два проекта library.rs и main.rs который чем-то из library.rs пользуется.
в library.rs допустим есть функция
func foo(a: &String) -> Result<Foo, E>
каким способом компилятор компилируя main.rs соединит всё это?
каким способом компилятор компилируя main.rs соединит всё это?
При помощи того самого интерфейса. Который будет написан первым и в котором указаны все нужные функции с их сигнатурами.
Потом я беру этот интерфейс, пишу библиотеку с функциями которые его имплементируют и компилирую её.
И точно так же мой клиент берёт этот интерфейс и пишет код, который должен использовать эти функции. И компилирует его.
Более того если интерфейс известен, то кто угодно может писать сколько угодно библиотек, которые имплементируют этот интерфейс. И точно так же кто угодно может писать кучу разного кода, который потом будет использовать эти библиотеки.
Вы действительно никогда не работали с интерфейсами?
При помощи того самого интерфейса
что мешает препроцессору пользоваться интерфейсом?
Пользоваться? Ничего не мешает. Вот только создать или "пометить" его препроцессор не может в принципе. Это должен делать кто-то другой. А вы выше написали:
Кем помечена? человеком? плевать на его пометки, их будет расставлять препроцессор
Так как препроцессор должен расставлять пометки? И если это делает человек, то как гарантировать что он это сделает правильно?
Пользоваться? Ничего не мешает. Вот только создать или "пометить" его препроцессор не может в принципе.
почему не может?
имеется функция.
она возвращает Result<T,E>? да — идём налево, нет — идём направо
блок обработки этого Result<T,E> на более верхнем уровне справляется полностью (не делегирует E наверх)?
да — налево, нет — направо
вот и разметили
остаются функции (весьма редкие) принимающие функции в виде аргументов, на них либо забить либо решить одним из предложенных выше способами
для Раста, кстати, как типизированного языка, две копии функции будут хорошо работать.
Почему не может?
Потому что интерфейс есть, а кода к нему ещё нет.
имеется функция.
Откуда она взялась? Сначала пишется интерфейс и раздаётся всем. После этого кто угодно может писать разные варианты имплементации этого интерфейса. Или не писать.
И например тот, кто собирается использовать эту функцию, свой код написал раньше чем хотя бы один вариант имплементации этой функции был написан. Откуда его препроцессор должен знать будут там исключитения или нет?
Потому что интерфейс есть, а кода к нему ещё нет.
в интерфейсе написано Result? Да? нужно оформлять как исключение
Нет? не нужно оформлять как исключение
То есть всё-таки "пометки" должен делать человек и препроцессор один с этим не справится. Отлично с этим пунктом мы разобрались.
Теперь следующий пункт: как гарантировать что человек всё сделает правильно? А не будет например так что в сигнатура функции написано что исключений быть не должно, а кто-то внутри использует функцию/библиотеку которая их бросает? Или наоборот что в сигнатуре указано что исключения возможны, а в коде не используется ничего что может их бросать?
То есть всё-таки "пометки" должен делать человек и препроцессор один с этим не справится
справится, просто в случае с препроцессором пометок человек будет делать на два порядка меньше
пометками будут факты применения операторов выброса исключения и его ловли.
а всё остальное может быть авторазмечено
справится
Как? Вот вам интерфейс с сигнатурой функции: "bool IsTrue()".
Можете дать мне пример препроцессора, который по этой информации может сказать будет эта функция бросать исключения или нет?
пометками будут факты применения операторов выброса исключения и его ловли.
Какие "факты применения"? У вас есть интерфейс и всё. Кода ещё нет. Откуда ваши "факты применения возьмутся"?
У меня всё больше и больше растёт подозрение что с интерфейсами вы никогда не работали...
Как? Вот вам интерфейс с сигнатурой функции: "bool IsTrue()".
не бросает исключения. чего проще-то?
напомню: интерфейс — это уже то что ПОСЛЕ препроцессора получилось (если он использовался)
Какие "факты применения"?
обычные: пользователь написал try-catch — значит здесь есть обработчик — факт
пользователь написал throw/raise — значит здесь есть генерация ошибки — второй факт
не бросает исключения. чего проще-то?
Нет, бросает. Потому что я возьму и так напишу эту функцию.
напомню: интерфейс — это уже то что ПОСЛЕ препроцессора получилось (если он использовался)
Давайте я вам ещё раз напишу: интерфейс это то, что создаётся в первую очередь. Это контракт. О нём сначала договариваются, а потом уже кто-то начинает писать код.
пользователь написал try-catch — значит здесь есть обработчик —
Пользователь ещё вообще ничего не написал. Он может начать что-то писать только после того как вы дадите ему интерфейс.
И я теперь понимаю что вы точно никогда не работали с интерфейсами...
Нет, бросает.
нет не бросает. Потому что с исключениями там будет не bool а Result<bool, Error>
Ну да, если я это туда напишу. А если забуду, то останется bool, а исключения всё равно будут.
Как ваш препроцессор должен там написать Result<bool, Error> если он не видит мой код?
Ну да, если я это туда напишу. А если забуду, то останется bool, а исключения всё равно будут.
если вы что-то забываете то раст перестаёт компилировать и напоминает.
я не понимаю, вы последовательными мессаджами издеваться пытаетесь или правда в непонимающего играете?
Я не понимаю как в расте или где-то ещё ваш "препроцессор" должен ставить какие-то "пометки" в интерфейс если кода под этот интерфейс ещё не существует.
если интерфейса ещё не существует, то что вы о нём так печётесь? напишите его и только после этого выясняйте список проблем, который можно составить.
при написании интерфейса так же можно использовать препроцессор расставляющий Result где нужно и не ставящий там где это не требуется
если интерфейса ещё не существует, то что вы о нём так печётесь?
Например потому что несколько команд или даже фирм одновременно начинают работать над чем-то, где этот интерфейс используется. Они не могут параллельно создавать свои варианты этого интерфейса. Он должен быть общим для всех.
То есть ладно вы с интерфейсами никогда не работали. Но это же базовые вещи. Неужели сейчас этому не учат?
при написании интерфейса так же можно использовать препроцессор расставляющий Result где нужно и не ставящий там где это не требуется
Так а откуда этот препроцессор должен знать где требуется, а где нет? Кода то ещё нет. Рэндомно ставить?
Так а откуда этот препроцессор должен знать где требуется, а где нет? Кода то ещё нет. Рэндомно ставить?
брать из интерфейса. если там Result проставлен — обрабатывать ошибку, нет — нет.
если вы там рандомно ставите Result, то препроцессор, так же как и компилятор Rust будет соответствующе реагировать.
я вообще не понимаю ваших последних сентенций
Вы издеваетесь? Как препроцессор должен одновременно брать ваши "пометки" из интерфейса сам же их туда прописывать? Вы же пишите:
при написании интерфейса так же можно использовать препроцессор расставляющий Result где нужно и не ставящий там где это не требуется
Как препроцессор должен это делать если кода нет?
Вы издеваетесь?
мне кажется — вы
Как препроцессор должен одновременно брать ваши "пометки" из интерфейса сам же их туда прописывать?
брать и прописывать
Вы же пишите:
вас не учили что есть такие утилиты, как, например make? вы никогда не слышали, что когда собирают целое из зависимых друг от друга вещей, то сперва строят граф зависимостей и затем обходят его так, чтобы при построении зависящего, зависимости уже были простроены?
нет?
неужели теперь такому уже не учат? (ц) Kanut
брать и прописывать
На основании какой информации?
вас не учили что есть такие утилиты, как, например make?
Нет, меня не учили что при помощи утилит вроде make можно генерировать интерфейсы с чистого листа. Не расскажите как это должно работать?
вы никогда не слышали, что когда собирают целое из зависимых друг от друга вещей, то сперва строят граф зависимостей
Конечно слышал. Вот только это работает исключительно если все эти части уже готовы и имеются в наличии. А их сначала надо написать. И интерфейсы кто-то должен прописать до того как вы что-то там начнёте собирать. И даже до того как вы начнёте работать над имплементацией этих ваших "зависимостей".
На основании какой информации?
- если на входе файл с расширением .rse, то на основе наличия try/catch/throw
- если на входе файл с расширением .rs, то на основе наличия Result<T,E>
чего проще-то?
Так а откуда должны взяться эти ваши "файлы с расширениями"? Никаких файлов ещё нет. Мы на стадии создания общего контракта. Код ещё не написан.
Так а откуда должны взяться эти ваши "файлы с расширениями"? Никаких файлов ещё нет.
командная строка,
$ vim src/main.rsНу отлично. Теперь у вас есть пустой файл main.rs. Как ваш препроцессор создаст из него интерфейс с "пометками" о исключениях?
Или это сначала надо всё самому делать? А препроцессор ваш тогда зачем нужен? Тогда и компилятора будет достаточно.
это растовый файл, в нём препроцессор будет смотреть функции возвращающие Result
И зачем это надо? Если я уже всё равно всю работу сделал?
у вас пока пустой main.rs, вы ещё не решили что такое интерфейс. вроде недавно на лекции услышали, но тут всё разбилось о зависимости
Если он пустой, то откуда там функции и на что тогда будет смотреть препроцессор?
в вашем случае — увидит пустой файл, выдаст на выходе такой же пустой.
это же препроцессор! вы чего-то ещё хотели? чтобы он за вас код написал? нет, он просто позволяет вам улучшить лаконичность: вместо 100500 символов напечатать 50250
Нет, меня не учили что при помощи утилит вроде make можно генерировать интерфейсы с чистого листа. Не расскажите как это должно работать?
тот вопрос, что вы задали не был про генерацию интерфейсов, а про обработку зависимых друг от друга частей.
Конечно слышал. Вот только это работает исключительно если все эти части уже готовы и имеются в наличии. А их сначала надо написать.
ну дык напишите, сперва интерфейс.
ну дык напишите, сперва интерфейс.
Отлично, написал. Но без "пометок" о исключениях. Как ваш препроцессор теперь будет эти пометки расставлять?
Отлично, написал
на расте написали? препроцессор по прописанным вами Result примет решение
на расте с исключениями? тогда интерфейс сперва получите пропустив его через препроцессор и возвращайтесь к предыдущему пункту
Так а в чём тогда заключается "проставление меток препроцессором"? В том что он продублирует уже написанную мною информацию? Причём один в один? И зачем он тогда нужен? Всё равно уже всю работу я сделал. И при этом если я где-то ошибся, то он просто мои ошибки повторит...
Если функция возвращает Result<T,E>, то это можно читать как "может вернуть T, а может бросить исключение E".
именно так.
если функция содержит в своём коде оператор throw или raise (или какой выберем) то она может бросить исключение
далее рассматриваем функции которые она вызывает: если какая-либо из них может бросить исключение, то наша функция может бросить исключение
перехват исключений для простоты пока отбросим.
можно же таким образом без участия пользователя разметить "бросает исключение/нет"?
Нет, нельзя. И на это есть две существенные причины:
Во-первых, нелокальность - такая разметка требует всей кодовой базы (и, например, для библиотеки, в которой используются коллбеки, вообще невозможна). А компиляторы очень любят локальность (например, растовский лайфтайм - это локальное свойство, которое нужно проверять только внутри каждой функции - если контракты на всех вызовах выполняются, то и глобально выполняются)
Во-вторых, функции высшего порядка. Функция, которая берёт другую функцию как параметр должна каким-то образом уметь понимать, нужно ли ей проверять наличие эксепшенов или нет.
Во-первых, нелокальность — такая разметка требует всей кодовой базы
- почему нельзя библиотеки размечать?
- если говорить о препроцессоре, то почему нельзя библиотеки размечать по сигнатуре Result<T,E>?
А компиляторы очень любят
не компиляторы, а их писатели. любят чтобы было попроще.
а ещё писатели линтеров. и пускают поветрия "вы лучше сами помучайтесь, чем мы за/для вас что-то поделаем"
Во-вторых, функции высшего порядка. Функция, которая берёт другую функцию как параметр должна каким-то образом уметь понимать, нужно ли ей проверять наличие эксепшенов или нет.
во первых решабелен и этот вопрос
во вторых даже если тупо отказаться от его решения (снизив эффективность) — это будет незначительное в общем снижение эффективности — плата за ЗНАЧИТЕЛЬНОЕ повышение читабельности кода
почему нельзя библиотеки размечать?
если говорить о препроцессоре, то почему нельзя библиотеки размечать по сигнатуре Result<T,E>?
Размечать людьми или автоматически? Проблема с функциями бОльшего порядка остаётся, если автоматически. А если руками, то нужно уметь каким-то образом сказать, что можно передавать в качестве аргументов только функции не бросающие исключения. Как это предлагается делать?
не компиляторы, а их писатели. любят чтобы было попроще.
а ещё писатели линтеров. и пускают поветрия "вы лучше сами помучайтесь, чем мы за/для вас что-то поделаем"
Любые операции на всей кодовой базе - это сложно и дорого. Например, исчезает инкрементальная компиляция.
во вторых даже если тупо отказаться от его решения (снизив эффективность)
Если размечать автоматически, то эффективность снижается не локально, а глобально - теперь любая функция, которая вызывает нашу функцию большего порядка, тоже размечена как бросающая эксепшен.
блин да почему же?
По правилам разметки. Функция, которая не бросает исключения, не может вызывать функцию, которая бросает.
Если функция большего порядка всегда помечена как бросающая исключения (вне зависимости от переданных параметров), то свойство "может выбросить исключение" "заражает" все функции, которые её вызывают и далее вверх по стеку вызовов.
Вы же понимаете к чему это приведет? Можно сразу писать что все бросает исключение и закрыть тему.
Небосающие куски будут вроде noexept. Редко и аккуратно.
Да. И в итоге всё будет равномерно медленно. Я же ровно об этом. Есть три варианта:
Вызовы дешёвые везде, но обработка исключений дорогая
Вызовы везде дорогие, зато исключения обрабатываются без дополнительных расходов
Вызовы в местах, где могут быть исправимые ошибки дорогие, где таких ошибок быть не может - дешёвые, обработка исключений дешёвая.
Первый вариант - это классические языки с эксепшенами. Вторым вариантом никто не пользуется, потому что слишком дорого для каждого вызова что-то такое делать.
Третий вариант реализован в расте и го.
Третий вариант реализован в расте и го.
в расте и го этого варианта нет. ибо исключений в этих языках нет
Растовский Result<T,E> является прямым аналогом значения типа T либо исключения типа E.
Если мы договорились, что каким-то образом по сигнатуре функции нужно уметь понимать, какие эксепшены она вызывает, то дальше это вопрос синтаксический, а не содержательный.
Какую задачу можно решить эксепшенами (при этом, как мы договорились, checked), но нельзя Result?
Какую задачу можно решить эксепшенами (при этом, как мы договорились, checked), но нельзя Result?
лаконичность. восстановления утраченного KISS-принципа
В каком месте символ "?" не является лаконичным? Вызови функцию, если она может выбросить эксепшен, но ты не планируешь обрабатывать его сейчас - одним символом он пробрасывается выше. То, что тип Result нужно писать программисту руками, а никакой пре-процессинг этого сделать не может, вы обсуждаете в соседнем треде.
В каком месте символ "?" не является лаконичным?
в неуниверсальном
берём например YamlLoader из раст-ямль
и fs::read_to_string из std
в одной функции сперва читаем ямль с диска, затем сплавляем ямль лоадеру YamlLoader::load_from_str
пробуем поставить вопросики и раст нас начинает насиловать:
- или рисуй enum двух разных типов error
- или откажись от вопросиков и обрабатывай на месте
и то и то геморрой, который мог бы быть скрыт под капотом, не испорти этот старый маразматик оба языка
Можно сразу писать что все бросает исключение и закрыть тему.
это — причина популярности языков с типами. Лень работать над линтерами, потому рекомендованы типы.
но "можно сразу писать" != "нужно сразу писать"
А зачем делать что-то что не работает? Checked exceptions в Джаве попробовали. Не работает. Второй раз по тем же граблям точно ходить надо?
вот честно про Джаву не знаю ничего.
очень часто "здесь не получается не потому, что невозможно, а потому что здесь так сделано (и надо переделывать) что именно здесь невозможно"
Мейнстримный язык. Который попробовал заставить проверять исключения или явно их передавать выше по стеку. И это оказалось грандиозной ошибкой дизайна языка.
Перед тем как пытаться придумать что-то новое стоит узнать что уже сделали другие и что из этого получилось. Не знать такую большую и такую типичную историю, ну такое себе.
Ну да. За суровую оптимизацию надо платить. Не надо ее использовать во всем обычном коде. Даже на Джаве я бы хотел такого. Аннотация "вот в этом методе мне не нужны проверки выхода за границу массива, если оно произошло нужно!!! уронить всю jvm с любой ошибкой" Буквально сотню строк на миллион таким я бы пометил. И это стоит того, я точно знаю. Авторы всяких интересных библиотек тоже порадуются.
На Питоне о таком не парятся вообще. Там бы разобраться почему вот эта строка там где ожидалось какое-то число неверно распозналась. И оно выстрелило в рантайме.
Это кто-то должен написать. С виду язык не запрещает так делать. Хороший код на тех же джава стримах доказано не имеет целых классов проблем. Я даже JEP правильно сформулировать не осилю. Увы.
А условный Хаскель или что-то такие оптимизации умеет?
У плюсов наследие и разнообразие такое что там так может и не выйдет.
По правилам разметки.
я потерял нить
что за правила разметки? кто размечает?
Не важно, кто размечает компилятор/препроцессор/программист или высшие силы.
Если в разметке получилось так, что "не бросающая исключения функция" вызывает "бросающую исключения функцию" и не ловит её ошибку, то эта разметка некорректна.
Если мы все функции высшего порядка помечаем бросающими исключения, как Вы предлагаете вот в этом комментарии: https://habr.com/en/post/709328/#comment_25112510 то любая функция, которая её вызывает и не проверяет вызов на ошибку тоже должна быть помечена как бросающая исключение.
Если в разметке получилось так, что "не бросающая исключения функция" вызывает "бросающую исключения функцию" и не ловит её ошибку, то эта разметка некорректна.
согласен. это баг разметки, который требуется поправить
Если мы все функции высшего порядка помечаем бросающими исключения, как Вы предлагаете вот в этом комментарии
то дочитаем комментарий о том, что таких функций в коде встречается редко — это во первых (и это причина забить на эту просадку перфа)
и во вторых решабельна и задача по данной проблеме.
навскидку: две функции высшего порядка под капотом и рантайм свитч между ними в зависимости от…
тупое решение, но будет работать.
можно рассмотреть и более изящные
то дочитаем комментарий о том, что таких функций в коде встречается редко — это во первых (и это причина забить на эту просадку перфа)
Так проблема в том, что одна редкая функция где-то глубоко по стеку вызовов "заражает" все функции вверх по этому стеку.
и во вторых решабельна и задача по данной проблеме.
навскидку: две функции высшего порядка под капотом и рантайм свитч между ними в зависимости от…
Чтобы что-то подставлять в рантайме, нужны дополнительные расходы.
В расте это сделано на этапе компиляции - можно написать код с Generic-параметром, который работает и для функций Result (и тогда тоже возвращает Result), и для функций возвращающих примитивное значение (и тогда возвращает примитивное значение).
Во время компиляции будут создано несколько реализаций (по одной для каждого использованного типа) и на этапе компиляции будет подставлена правильная.
Чтобы что-то подставлять в рантайме, нужны дополнительные расходы.
вообще забейте на это
прототип функции, передаваемой в аргументы известен всегда.
если принимается в аргументы Result<T,E> значит может бросать исключения, если нет — нет
это же раст. случаи где что-то не так — ошибка компиляции.
тьфу, мы обсуждаем то что и обсуждать не имеет смысла.
Очевидный ответ - компилятор вставляет другой код.
а что мешает вставлять тот же самый?
Видимо есть соображения, которые вы не знаете или не понимаете. Вы же не считаете себя умнее тех кто создает языки и компиляторы?
так озвучьте соображения, что трудно что ли?
Я их не знаю. Но это не мешает мне понимать, что они есть.
ну вот я сходил по ссылке и увидел что в случае если включают мютексы на многопоточном коде на момент разворачивания ексепшена, то да, медленнее
но это НОВОЕ ПРОДУКТОВОЕ ТРЕБОВАНИЕ к обработчику ошибок. поскольку сейчас в расте и го таких требований нет, все отлично живут без этого, значит можно не замедляться.
Довольно сильное утверждение.
Почему никто до сих пор не сделал компилятор, который делает эксепшены более дешёвыми, чем существующие? Если это возможно за разумное время?
а что значит "никто не сделал"?
прям во всех-всех языках так?
Я чуть выше вас уже просил привести пример такого языка. Желательно не совсем экзотического.
С++
Perl
да даже Python
Во всех них исключения дорогие, см. бенчмарки.
Плюсы вы серьезно? Там типичные очень дорогие исключения.
https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/
Питон сам по себе очень медленный. Там бесполезно что-то тестить на скорость. Не для скорости работу кода он сделан.
Про Перл увы ничего не знаю.
- я серьёзно
- по ссылке невалидный бенчмарк
сравнивается чистый return без проверок с ексепшеном в котором под капотом проверки, очевидно что будет разница
так же как в расте написать две функции
func foo() -> i32
func foo() -> Result<i32,Error>очевидно, что первая (В СОВОКУПНОСТИ) будет быстрее. почему?
во первых возвращает одно число
во вторых результат второй нужно пропускать через match
но мы говорим что если Result зачем-то есть, значит эту звезду зажгли потому что так нужно ведь?
Вот люди пишущие про стандарт. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html Результат тот же самый.
Наверно они понимают в бенчмарках?
если сравнивают так же как предыдущие — нет.
ещё раз: в предыдущем бенчмарке сравнивались исключения, включающие в себя
- возврат ошибки
- проверку того что она произошла
- поиск блока обработки
- передачу ошибки этому блоку
с
- просто возврат значения
в этом смысле исключения всегда будут медленнее.
но Result<T,E> — это первый вариант, а не второй. если побенчмарать
return T vs return<T,E> то удивительно, но второе тоже будет бенчмаркать хуже.
но с этим живут?
а препроцессингом сфолдить такое до не худшей производительности вполне можно
Вторая ссылка это текст предложения в стандарт плюсов. Вы абсолютно точно уверены что там бенчмарк неверно написан?
Почему исключения сделаны именно так дорого, а не иначе дешево это другой вопрос. Пока стоит остановиться на том факте что исключения во всех типовых языках это очень дорогая операция. И видимо есть глобальные причины почему это так. Потом можно будет продолжить выяснять что это за причины.
Вторая ссылка это текст предложения в стандарт плюсов. Вы абсолютно точно уверены что там бенчмарк неверно написан?
я не могу увидеть что там во второй ссылке за бенчмарки, у меня этот сайт так криво отображается, что меню закрывает большую часть текста. ХЗ почему так, видимо надо написать вторую статью про то "что они сделали со фронтендом" :)
сумел таки продраться к тексту.
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> не ставят мютексы
И вы получаете Go'шный результат. Где разработчик обязан писать бойлерплейт после каждой функции. За редкими-редкими исключениями.
Это другой результат, но есть сомнения в том что он лучше.
бойлерплейт раста и го одинаковый
Нет, конечно. Можно пример if err != nil в каком-нибудь достаточно известном проекте на расте?
Можно пример if err != nil в каком-нибудь достаточно известном проекте на расте?
дык
match result {… =>… }
это вот прямо тот же самый if
match result - это, скорее, аналог try/catch блока, если с err что-то происходит.
А если ошибку нужно просто пробросить, то в расте бойлерплейт не нужен.
match — просто набор if'ов ничего более
А если ошибку нужно просто пробросить, то в расте бойлерплейт не нужен.
выше пример где нужен (ямль + std error)
выше пример где нужен (ямль + std error)
Где бойлерплейт вот в этом решении: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6786c5d8cc73f485c0a6780a01b229d4 ?
стоки 1, 2 и 4
Простите, вечером прислал не ту ссылку.
Вот правильная ссылка: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2662fec2621b9d9f65660649551d21ff
Объединят, как и ожидалось, std::io::Error и yaml::scanner::ScanError без дополнительных усилий.
Это будет медленно там, где есть Result и быстро там, где его нет. При этом там где он есть, проход по ошибке будет примерно так же быстр, как и проход без неё.
именно так. и Result может расставлять препроцессор а не человек
Не может, мы это обсуждали уже. Потому что, например, у колбеков тип "возвращает int32" и "возвращает Result<int32, IOError>" - это два разных типа (после препроцессора, но не до!) и возникает проблема с функциями высшего порядка.
не возникает, разобрали уже.
типы не дадут в один колбек запихивать два разных варианта, а если всё же хочется — придётся enum лепить.
так что здесь не то, что нерешаемых, вообще никаких проблем нет
Enum - это плохое решение, потому что если в функцию можно запихнуть возвращающий E-вариант callback, то функция должна сама уметь возвращать exception (и тогда её нужно пометить как бросающую эксепшен).
Есть возможность сделать два варианта функции с колбеком - когда на входе колбек не бросает и функция сама по себе не бросает, и вариант для колбеков, которые бросают.
Если выбор функции случается автоматически (без участия человека), появляется проблема с тем, что выбраться не та, которую ожидал человек и всё станет катастрофически медленнее.
Если выбор функции случается автоматически (без участия человека), появляется проблема с тем, что выбраться не та, которую ожидал человек
не появляется. поскольку на стадии компиляции однозначно понятно какая куда
Так это, собственно, задача прописывания типов. Если типы прописаны (напрямую или с помощью дженериков) - понятно. Если не прописаны - непонятно.
пользователь оперирует типами идущему по mainflow, а препроцессор заглядывает есть ли errorflow (факт использования throw) и расставляет Result или нет.
Если типы только по mainflow и никакой обработки (try-except) в коде нет, то Result вообще не нужны, сегодняшний rust так тоже умеет, достаточно писать unwrap.
Если какая-то обработка ошибок всё-таки ожидается, то как они должны меняться?
достаточно писать unwrap.
unwrap — это panic
unwrap — это снижение лаконичности
Так эксепшены без try-блоков неотличимы по поведению от паники, разве нет?
Лаконичность теряется только в взаимодействии с другими библиотеками, и, естественным образом, делается один раз на каждую функцию максимум (при этом не один раз в каждом проекте, а прямо глобально один раз).
Так эксепшены без try-блоков неотличимы по поведению от паники, разве нет?
и? каким это тут боком?
Лаконичность теряется только в взаимодействии с другими библиотеками
в каждой первой функции не нужно
- возиться с вопросами unwrap, match, или расставлением вопросиков
- врапать возвращаемые значения в Ok/Some/Err/итп
Вопросики нужны только для функций, которые могут возвращать ошибочное значение. Для тех, которые не могут возвращать (при этом и вызываемая функция может не возвращать, и вызывающая, достаточно любого одного) вопросики писать не нужно.
В традиционных исключениях тоже нужно писать два разных слова return и throw, чтобы отличать основной путь выполнения и ошибочный. Если так не нравится писать Ok/Err никто не мешает себе завести макрос throw!, заворачивающий в Err, и retur!, заворачивающий в Ok.
Растовская - точно не разрешима, она тьюринг-полная: https://sdleffler.github.io/RustTypeSystemTuringComplete/
Потому что проблема останова неразрешима. В тьюринг-полной системе эту задачу (для конкретной машины на конкретном входе) можно (вычислимо) сформулировать, что даёт сведение.
К слову о ChatGPT
Похоже, она подходит лишь для того, чтобы эссе написать, а так она выдаёт такое:
А также, захотев разобраться с тем, что такое Post's lattice, я получил "also known as the Post canonical system..."
В общем, пора перебираться в математики, чтобы нейросеть не могла заменить меня (любителя перекладывать джейсончики и байтики)
То и значит - никто не сделал, никто. Вообще никто ни в одном из языков, на которых пишет кто-то кроме автора языка.
Да, прям во всех, на которых пишет кто-то кроме автора языка.
Найдете контрпример - можем продолжить диалог.
что значит никто? в C++ прекрасные исключения. очень быстрые.
Result<T,E> раста не быстрее throw C++
Для кода, который не может бросать эксепшены - настолько же быстрый.
Для кода, который может бросать, но не бросает - да, чуть медленнее C++.
Для кода, который может бросать и бросает - быстрее C++.
Наверное потому что исключения в C++ настолько быстрые придумали даже ключевое слово nothrow, которое в рамках метода убирает супер-быстрые исключения, которые ничего не стоят.
Как быстро работает Result<T,E> раста по сравнению с throw C++ - пришлите ссылку на бенчмарк.
Ну конечно же это не так. Вы легко найдете бенчмарки на любом языке с исключениями и составите понимание их стоимости.
Я сначала даже удивился насколько дорогие исключения в .NET например.
Видимо компилятор вставляет гораздо больше кода для обработки исключений, чем вы привели. Как минимум нужен код для получения stack trace при выбрасывании.
Как минимум нужен код для получения stack trace при выбрасывании.
- стектрейс нужен в debug режиме
- для каждой ошибки он статичен, а потому стектрейсы тоже можно составлять на этапе компиляции (то есть не тратить время в рантайме): компилятору в общем случае всегда известно на сколько уровней поднимется по стеку эта ошибка или та до её перехвата
Я сначала даже удивился насколько дорогие исключения в .NET например.
а в Perl, например, они были весьма дёшевы.
стектрейс нужен в debug режиме
Он как раз в проде нужен. Чтобы по сообщению в логе понять где упало.
для каждой ошибки он статичен, а потому стектрейсы тоже можно составлять на этапе компиляции (то есть не тратить время в рантайме): компилятору в общем случае всегда известно на сколько уровней поднимется по стеку эта ошибка или та до её перехвата
А-ха-ха. Падает какое-нибудь чтение из файлика. Вы уверены что путь вызова всегда один?
Он как раз в проде нужен.
нет, он не нужен в проде совершенно.
вы сейчас отлично без него обходитесь, Result<T,E> может включать способы манипуляции стектрейсами, однако не включает.
следовательно и далее обойдётесь.
продуктовое требование "хочу стектрейс" однозначно требует за него заплатить
говорить же "меня устраивают ошибки" vs "если ошибки будут через синтаксис исключений, то мне обязательно нужен стектрейс" — это признак биполярного расстройства
Зависит от E. Есть стандартные решения, которые в E записывают stacktrace (например, уже упомянутый anyhow по умолчанию пишет трейс).
решения есть, но если их начать бенчмаркать с простыми Result<T,E>, то сюрприз: окажется что они бенчмаркают хуже
До тех пор, пока эксепшены не случаются - они стоят столько же.
В тот момент когда случаются - да, за наличие трейса нужно платить, это, вроде, ожидаемо.
трейс — дополнительное продуктовое требование.
если он нужен — за него платим
если он не нужен — его не формируем и всё бесплатно
Не бесплатно. Нет языков, в которых эксепшены (даже без трейса) бесплатны.
бесплатность измеряем относительно растового Result<T,E>
тут именно бесплатно получится
Бесплатность нужно сравнивать относительно T.
Если бы мы были готовы (по производительности) жить в мире, где любая функция может вернуть result, были бы более холиварные вопросы типизации.
вы сейчас отлично без него обходитесь,
Я временами на Джаве пишу. Стектрейсы в исключениях это великолепно. Они облегачют дебаг значительной части ошибок прям на порядок.
продуктовое требование "хочу стектрейс" однозначно требует за него заплатить
Это свойство языка. Поменять после первого релиза уже нельзя. Подумайте еще раз. И заодно посмотрите как у других сделано. Есть более одного решения. И почему сделано так а не иначе тоже почитать стоит. И заодно к чему эти решения привели в итоге тоже почитать стоит. Неглупые люди эти решения придумывали и неглупые люди годами или пользуются.
говорить же "меня устраивают ошибки" vs "если ошибки будут через синтаксис исключений, то мне обязательно нужен стектрейс" — это признак биполярного расстройства
У всех решений есть свои особенности. Надо просто знать их и уметь ими правильно пользоваться. Общего решения хорошего для всего тут нет.
Стоп. Я видимо был слишком уставший и голодный когда писал коммент, на который вы ответили, что даже не понял очевидную ошибку в ваших рассуждениях.
Если предположить что есть гипотетический компилятор 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. Как может компилятор вычислить насколько вверх по стеку поднимется ошибка?
Для C++ вообще все плохо так как почти везде автоматическая деструкция, поэтому почти везде добавляется обработчик эпилога в список
дык в расте обработчик эпилога ваяет сам разработчик в каждой первой функции
от С++ тут отличия только в том, что разработчик среднестатистически более низкоквалифицирован, нежели разработчик компилятора, а потому, следовательно, в среднем, перегруженная на него функциональность имеет худший перф, нежели не перегруженная
Не очень понимаю о чем вы.
При отказе от выбрасывания исключений мы не платим ни за блоки try, ни за перехват исключений. Вместо этого нам предлагается в часть методов прописать явную обработку кодов возврата. Пролог и эпилог функций не меняется.
У кодов возврата есть две проблемы: многословная проверка и возможность эти коды игнорить.
В Расте обе проблемы решены: атрибут #[must_use] не позволяет игнорировать Resut<T, Err>, а оператор ? разворачивается в if Err { return Err }. В простых случаях с помощью unwrap или expect можно грохнуть программу при ошибке, как в языке с исключениями при отсутствии их обработки.
В Go мало того что обе проблемы не решены, так еще и коржеж (значение, ошибка) не является не является выражением, что отрезает возможность сделать как в Rust. Самое смешное, что в Go при этом всем есть обработка исключений через panic и recover.
кто такие «мы»?
разработчики приложений на этом языке продолжают платить, причём платить гораздо дороже.
раньше (в С++) они платили только флопсами
теперь, в плюс к флопсам, они платят своим временем, расставляя однотипные обработчики ошибок по всему коду, захламляя доступ к пониманию алгоритмов.
кроме того, ещё раз: поскольку среднестатистический разработчик на раст по квалификации ниже среднестатистического разработчика компилятора этого языка, то его реализация кода обработки ошибок в общем случае бенчмаркает хуже, чем если бы это было сделано централизовано.
Разработчики не платят быстродействием программы.
кроме того, ещё раз: поскольку среднестатистический разработчик на раст по квалификации ниже среднестатистического разработчика компилятора этого языка, то его реализация кода обработки ошибок в общем случае бенчмаркает хуже, чем если бы это было сделано централизовано.
Опять не понимаю о чем речь. Можно пример того кода, который напишет среднестатистический разработчик Rust для обработки ошибок?
Я вижу два варианта: оператор ? и функции unwrap и except. Что по вашему вызовет проблемы? И какие проблемы?
ещё есть match, ещё есть варианты if let итп
а проблемы вызовет любой способ, применённый неправильно, как-то, например, повторные проверки итп
постоянное конструирование/деконструирование объектов Result явно бенчмаркает хуже, чем если бы централизовано под них просто выделили ОДНАЖДЫ по переменной на тред
Result - это не джавовский объект, под который нужно выделять много памяти, это просто enum с двумя возможными значениями. При этом, если хочется, его можно менять прямо на месте (и, в достаточно большом классе случаев, компилятор это даже за тебя делает).
В случае, если оба типа в нём указатели, то про него можно думать как про код возврата (вернулся результат или ошибка) + указатель на соответствующий объект (в первом случае на результат, во втором на ошибку). И весь ? или if let - это проверка кода возврата.
Можно подробнее что предлагается сделать?
Всегда проверять "код возврата"? Даже у функций, которые гарантированно не падают? Это будет дороже по перформансу.
проверять код возврата там где возвращаются ошибки (бросаются исключения), и не делать это когда они не возвращаются.
поскольку человек это всё равно делает, то компьютер и подавно справится
> Это будет дороже по перформансу
это будет дешевле по перфомансу, ибо будет писаться профи (и улучшаться со временем) а не каждый раз новым случайным разработчиком с нуля, пусть даже и копипастой со стековерфлоу
Именно, что обсуждалось.
Компилятору нужна разметка, чтобы знать, где проверять (см. noexcept).
всякую задачу можно решить разными способами. Выбор способов иногда определяется легаси, обратной совместимостью итп.
Новый язык может обойтись без noexcept, но реализовывать исключения на базе механизма аналогичного
result, error голанга или Result растаТак что Result, что result, error - это ручная разметка, а не что-то автоматическое. Если эта разметка уже делается руками, то Result выглядит хорошим решением - нельзя взять результат не проверив код возврата.
и резалт и тапл с резалтом — это один и тот же способ
longjump — чуть более другой
Так exception и в C++ не делает longjump.
Чем то одна, то две переменных на стеке хуже, чем всегда две, как Вы предлагаете?
а вот централизовано это вообще можно делать даже не на стеке.
Как предлагается узнавать, нужно ли читать эту централизованную переменную?
Если это общий код возврата, то почему Вы считаете, что переменная в куче будет быстрее, чем на стеке?
ну блин, десять раз выше обсуждалось
функция foo вызывает bar и baz
baz может выбросить исключение, bar не может
строим граф зависимостей и приходим к выводу, что foo тоже может.
соответственно контекст вызывающий bar не проверяет переменные (пофиг где они хранятся, на стеке ли или нет), а контекст вызывающий foo и baz проверяет
> Вы считаете, что переменная в куче будет быстрее, чем на стеке?
в общем виде ошибки, при развитии системы до большой, могут представлять большие объекты, аггрегирующие как тексты ошибок, коды, признаки восстанавливаемости итп итд.
вполне возможно МОЖЕТ (не обязательно) оказаться, что хранить их в виде «однажды выделенного в куче списка» будет выгоднее, нежели выделять при генерации и удалять после обработки.
ведь когда Result<T, E>, а E — это контейнер включающий в себя Struct, то с кучей уже де-факто работаем.
строим граф зависимостей и приходим к выводу, что foo тоже может.
Если это делает компилятор, то эту ошибку нельзя нигде выше по стеку проверить (потому что нужно запрещать проверять код ошибок функций, которые точно их не выбрасывают). Обсуждалось вот в этом https://habr.com/en/post/709328/comments/#comment_25117572 сообщении.
Если это делает человек, то где выигрыш?
Если E - контейнер, то он выделяется на куче только если что-то случится (и это в любом случае нужно выделять, вне зависимости от парадигмы, если мы хотим эту большую информацию получать при обработке). А простые структуры можно продолжать хранить на стеке (и раст продолжает).
Я если честно так и не понял что предлагается.
Что значит "проверять" и "размечать". Если проверять это просто пробросить наверх, то что может быть проще ? растового? А если мне не надо просто пробросить наверх, если ошибка это вобще часть нормального флоу, мне надо ее поймать, и сделать что-то внутри функции, тут компилятор как должен угадать что ее пробрасывать не надо?
Что значит препроцессор разметит? Ну во первых человек помочь не может, ведь в статье говорится что статическая типизация это от сатаны и все должны писать на динамике, так откуда взяться помощи препроцессору? Ну допустим мы своим же принципам не следуем и пишем на статике.
у нас есть функция `f1() -> Result<E,T> {...}`, есть вторая функция которая ее использует, я правильно понимаю что человек пишет так `f2() -> bool { ... let s = f1() ...}`, а препроцессор должен превратить ее в `f2_preprocessed() -> Result<bool,E> {}` ?, если да, то как мне как человеку использовать эту f2. как мне отличить f2() которая по сигнатуре не выдает ошибки, но самом деле выдает, от f3() ->bool{}, которая и по сигнатуре не выдает и на самом деле не выдает. Зачем мне отличать их? ну например чтобы просто залогировать ошибку при вызове функции из цикла. Почему мы вобще часть функций сами размечаем а часть нет, или мы все размечаем, но что тогда должен делать препроцессор?
Приятно читать человека, хорошо осмыслившего раскрываемый вопрос. Спасибо за статью.
В целом, я разделяю ваше отношение к процессам "разделения труда" и "отчуждения от результатов труда", а также к их следствиям для работников. Однако:
1) Утопия (просто используем этот термин для обозначения наших целей, не декларируя, при этом, их недостижимость) в рамках одной отдельно взятой отрасли - это "утопия в квадрате". Обычную утопию проще построить.
2) В описанной вами ситуации проблема не только в микросервисах, но еще и в догматизме. Создание монолита для одной лишь озвученной в истории задачи (в качестве исключения) не привело бы к разрушению "системы отчуждения от результатов труда", но спасло бы для бизнеса миллиарды. Догматизм плох и для другой стороны, к слову.
Одна из лучших статей на Хабр за всю историю его существования. И я не согласен с половиной того, что написано.
Хорошая статья, только на Маркса надо было ссылаться сразу в первом абзаце - чтобы сэкономить время читателя.
Попробуем расставить точки над "Ё" в слове "марксизм".
1. Тяжелый, отупляющий труд - это плохо для рабочего.
2. Капиталист хочет этого, чтобы он мог заработать.
3. Скорее всего обществу в целом от этого будет лучше - больше качественных и дешевых товаров.
Выводы.
За тяжелый, отупляющий труд надо платить больше. За творческий и интересный - меньше. Тогда можно установить некий общественный баланс - художникам нужны рабочие на конвеере хотя бы чтобы последние штамповали кисти. При этом творческий и интересный труд может иметь отрицательную стоимость. Много музыкантов кто тратится на репетиции, инструменты, и т.п... выступает в клубах (создавая ценность для слушателей), и ничего на этом не зарабатывает. Или писатели с самлиба/самиздата. Или программисты создающие СПО.
Но! Эта стройная система начинает усложняться. Ибо экономическое принуждение - есть люди кто не может заниматься интересным и творческим трудом (по совокупности любых причин), и зачем этим людям платить больше если их можно заставить экономически (т.е. угрожая голодной смертью) работать на конвеере? Дальше (например) эти работники могут объединиться в профсоюзы, потребовать увеличения ЗП, и всё опять усложнится.
Видимо экономические модели потому плохо и работают, что много важных факторов действуют одновременно и результат не объясняется простыми моделями которые помещаются в голове. Т.е. надо писать систему уравнений и результат будет непредсказуем, особенно учитывая неустойчивости.
То, что Вы описываете как систему усложняющуюся (развивающейся или деградирующей), безусловно таковой действительно является - это фактическая абсолютная правда, с которой никто и спорить не будет (возможно, уточнять детали). Тем не менее, в дальнейших рассуждениях хотел бы уточнить.
Так вот, марксизм развивает диалектику Гегеля, постулируя: "усложняющиеся" (развивающиеся или деградирующие) "системы" (а точнее сказать, материи - общественная материя, биологическая, ..., так как усложняется именно сама материя) развиваются или деградируют в процессе противоречий и борьбы. Определить ключевой мотив борьбы, её "законы", и позволит определить тенденции развития (причем как "развивающие", так и "разрушающие"). Вернёмся к Вашему комментарию.
Выводы.
За тяжелый, отупляющий труд надо платить больше. За творческий и интересный - меньше. <...>
Кому это надо? Пролетарию (наёмному работнику, продающему своё время и труд) или капиталисту (владельцу производства) - ведь он по п.2 по-прежнему существует? Или, может быть, подклассу мелкой буржуазии (люди, которые работают на своих средствах производства и сами же продают свои результаты труда на рынке)?
Классовая борьба - это как раз и есть борьба, выстроенная на неустранимом противоречии интересов, всю дорогу развивающая капиталистическое общество, всякое действие или бездействие в ней представляет интересы классов, и в борьбу вовлечено абсолютно всё общество, особенно государство.
Классовая борьба пролетариата породила те самые профсоюзы, выходные дни, нормированный рабочий день, усиленную оплату переработок и вредности, пенсии, а классовая борьба капиталистов отыграла, породила пенсионную реформу, ненормированный рабочий день, систему штрафов, а также даже всякие разные события, из-за которых люди вынуждены переселяться (из-за чего цены и заплаты меняются тоже не в пользу трудящихся), и так далее. Часть этих мер была выгодна даже капиталистам (например, нормированный рабочий день повышает эффективность труда, достойные условия труда также этому способствуют), но тут уже надо помнить, что они тоже между собой конкурируют, и очень сложно выжить как предприятие, имея под боком ничем не сдерживаемого конкурента-"людоеда" (а точнее, не одного, а очень много), который заставляет рабочих работать в адских условиях по 16+ часов в сутки, потом выбрасывает этих несчастных рабочих как отработанный материал, приплатив им скажем всего лишь в полтора раза больше, чем может позволить твоё "доброе" предприятие. Потому что в интересах капиталиста действовать таким образом (а будет ли он в ней действовать - его воля, и, к слову, его произвол), и решить это могут только наёмные работники (в чьих интересах, осознают они это или нет, как раз всё это "людоедство" ликвидировать), которые в отдельности несоотносимо слабее, но в целом оказывается, что на них всё и держится.
Ну а своей высшей фазе развития капитализм срастается корпорациями с государством, и заполненные рынки сбыта (и труда (!) требуется уже делить, увеличивая сходящую почти к нулю норму прибыли (называется всё это империализмом). Как делить - ну, например как в 1914. Рыбой, которой нельзя говорить "нет". Сначала локально выпуская эту рыбу, она постепенно захватывает весь мировой океан (ибо всё больше интересантов), а трудящиеся страдают и многие даже гибнут.
То, что Вы описали как модель, действительно будет усложняться и усложняться (причем обрастать внезапными обстоятельствами, пришедшими из материальной природы общества). Марксизм пришёл вовсе не к этому (он с этой посылки, можно сказать, начал, постулируя существование классовой борьбы), а пришёл к тому, что либо противоречие будет позитивно снято (пролетарии возьмут власть и в итоге построят бесклассовое общество, потому что они это как раз могут сделать), либо в мире будет приблизительно как у Оруэлла (и кстати да, кто-то из капиталистов даже может назвать себя "социалистами", для запутывания трудящегося... один австрийский художник именно так и поступил, к слову). Как сказала Роза Люксембург, "Социализм или варварство". А попытка "уравновесить интересы" невозможна, потому что любые "судьи" классов будут действовать в интересах настоящего правящего класса.
Спасибо за развернутый комментарий!
Когда я пишу "надо платить больше" - да... я имею ввиду некую глобальную справедливость, (впрочем возможно у меня сознание деформировано советским социализмом). Можно переформулировать - "человек должен больше получать", но суть в общем та же. Строчка "Здесь мерилом работы считают усталость" - вполне имеет смысл оказывается.
возьмём IT'шника и учителя
вопрос: почему IT'шник зарабатывает значительно больше?
у него работа более социально значимая? — нет
у него работа более изматывающая? (усталось — мерило) — нет
или другой пример, врач и учитель:
Востребованность работы бизнесом? Т.е. на IT бизнесмены зарабатывают больше чем на учителях и врачах. Возможно, если срезать ЗП банковским ITшникам наполовину, удалось бы на 0.5% уменьшить процент по ипотеке выдаваемый банком ))). Еще у учителя и врача в массе невнятные критерии работы.
Пришел человек к врачу, ушел... и что? Вылечился? Забил на болезнь и страдает, ушел к другому врачу, умер? И с учителями так же. Хорошие врачи и учителя (С) (репетиторы) зарабатывают обычно хорошо, но там работает сарафанное радио - довольный результатом человек рссказывает всем о своих успехах.
но в среднем меньше плохих IT'шников
Есть страны, где врачам и учителям нормально платят.
при том, что у учителей работа куда большей квалификации требует.
JSON'ы передвигать — много ума не нужно. Психологических сил же вообще не требует
на уровне IT'шников учителям в среднем не платят нигде.
А врачам?
Средняя по врачам оплата будет куда ниже чем средняя по айтишникам. В любой стране.
При том, что врачу нужно долго и много учиться, а айтишником может стать любой дворник, достаточно выучить пару магических слов, вроде «Монады» и кидать их направо и налево.
Средняя по врачам оплата будет куда ниже чем средняя по айтишникам. В любой стране.
Правда? А мне гугл почему-то говорит что средняя зарплата врача в Германии больше 80к€ в год. А средняя зарплата айтишников где-то 60-70к€ в год.
И что-то у меня есть подозрение что как минимум в Голландии, Швейцарии или там Австрии ситуация будет похожая. А скорее всего не только там.
Смотрим на реальные данные, а не левацкие фантазии:
Врачи: медиана составляет $339k в год в США.
Разработчики: медиана составляет $120k в год в США.
Размеры США(третьей страны по населению на планете после Китая и Индии), а также слово "медиана" намекают, что врачи как раз таки массово получают больше разработчиков.
Для врачей:
— в данные включены только full-time (т.е. нет «полставочников»)
— в данных дана вся «годовая прибыль» (т.е. всё что получил минус налоги и сборы), а не зарплата
— большинство врачей получает деньги на переработке
— многие (треть) подрабатывают ( в т.ч. и на слабо связанных с медицинской деятельностью работах — с чего бы это?)
т.е. если бы программисты в своей массе работали бы (оплачиваемо!) сутками, то и у них доходы бы были повыше. А если включить все «халтурки»…
Плюс медиана здесь как среднее — похо катит, т.к. распределение зарплат — не гаусово. У тех, кого называют врачами в США — нет туевой хучи джунов-кодеров веб страничек.
Я думаю что указана «годовая прибыль» потому что куча врачей "самозанятые", то есть имеют свои врачебные практики.
И да, сравнение не то чтобы особо удачное. Но я бы сказал если даже сравнивать "по честному"(то есть с там учётом переработок или там брать только айтишников с ВО), то всё равно врачи в США(и куче других западных стран) будут в среднем получать больше айтишников. Или как минимум не меньше.
А сколько зарабатывает плохой IT-шник? И кто это кстати?
Двоякие ощущения от статьи. С одной стороны, конечно, говорить об отчуждении труда надо, это очень важный разговор. С другой, так хейтить именно микросервисы... Как было уже сказано выше, это просто логичный способ повышения эффективности труда. Это невозможно остановить. Заходить надо с другой стороны: а кто вообще программистам даёт задание писать очередной 100500-й криптокошелёк? Какая потребительная стоимость при этом создаётся? Сколько жизней от этого станет лучше? И так далее.
Ну и про линтеры. Тут автора уж совсем понесло. Единые правила написания нужны лишь для удобства чтения коллегами и самим собой позже. Автор, вас смущает, что все люди пишут комментарии следующим образом: каждое новое предложение с заглавной буквы, в конце точка, между абзацами перенос строки? Может, в школе правописание отменить, заодно и грамматику выкинуть?
Вы правы, только ничего не сможете сделать.
Бизнесу важна масштабируемость - т.е. максимизация совокупного дохода. Найти ещё пяток уникальных челов - сложно, а выучить за 2 недели тысячу мотивированных потребностей - понятно и просто.
Кроме того, контролировать 3-х уникальных сложнее, чем тысячу переключателей.
Спорная штука.
Тенденции, конечно, есть. Но они есть с момента изобретения конвейера.
Микросервисы в данном случае всего лишь технологии.
И поставить раком персонал прекрасно можно и в «монолите» (собственно в "монолите" в стойло загонять и стали - все вышеописанные стандарты, подходы, поветрия и суеверия были изобретены когда словосочетания "микросервис" не существовало)
Видимо автор не был связан с проприетарными языками жестко привязанными к платформе. Тот же ABAP, например.
Кстати, PowerBuilder образца 90х точно так же вводил жесткую регламентацию, включая правила именования всех объектов. Т.е. там даже функцию HelloWorld создать было некошерно.
Увы, большинство IT'шников склонны понимать текст буквально (фрагментарное мышление), не видеть ни шуток, ни гипербол, обсуждать строго частности и не смотреть на целое.
Данная статья — попытка с таким явлением бороться
большинство IT'шников склонны понимать текст буквально
Потому что при попытке понять не-буквально совпасть в интерпретации с автором текста можно только случайно.
Обвинение во фрагментарности мышления - очень удобный способ отказаться от защиты собственных тезисов.
А какой смысл с этим бороться? как говорила моя бабушка: не трогай - не будет пахнуть.
В вашей логике, что этот низкоквалифицированный труд вытесняет что-то прекрасное есть явная ошибка из локальных наблюдений. Вы просто сравниваете разные рынки труда.
Вы сравниваете зп(мотивацию) для низкосортного рабочего на глобальном рынке (в глобальном плане эти доходы действительно ничтожны), и мотивацию для профи на локальном рынке. И это сравнение рождает негатив - так как наш рынок низкобюджетный.
На самом деле профи ценится выше - что логично. Но на рынок, где это ценится, трудно попасть.
Обычно в командах эти форматтеры как раз освобождают творца, не давая ему погрязнуть в несущественных мелочах и вкусовщине.
Ну а линтеры помогают не закапываться в глупых ошибках.
> Именно Дейкстра был основателем первой крупной секты хейтеров нормальной, в общем-то, технологии. В результате миллионы людей осудили инструмент только потому, что какой-то «авторитет» что-то там сказал.
Вот тут уже начинается какой-то смысл. Неиспользование goto нужно было не само по себе, а чтобы воспользоваться правильным, доказуемым структурированием программы. И да, я согласен, что этот тезис слишком часто превращают в религию.
Про микросервисы в Яндексе ничего не скажу — административные заморочки структуры такого типа сложно объяснимы. Ну и остальная типа-философия как-то чрезмерна.
Но именно рассказ про административную сторону микросервисов заслуживает публикации хотя бы с точки зрения популяризации :)
Мой папа такой подход называет занятостью населения.
К статье только одна претензия и она не к содержанию, а к оформлению. Зачем использовать сноски (одну сноску (!) на список ссылок внизу статьи) и не использовать ссылки прямо в тексте? В чём смысл, зачем так делать? Это же очень неудобно скакать туда сюда вместо того, чтобы просто одним кликом открыть ссылку в новой вкладке браузера! Это же интернет, а не статья в бумажном журнале, гипертекст придумали 50 лет назад.
Ну и, вероятно, я не согласен на счёт авто-форматтеров кода. Автоматически форматировать код в едином стиле — это всё таки полезно и правильно. Это как раз таки высвобождает ресурсы и оставляет место для творчества в другом месте.
Наверное всё же не в микросервисах дело. Я и до появления микросервисов встречал программистов, которые жаловались на механическую тупость своей работы, они были загнаны в рамки корпоративной версии языка Basic (в котором кстати не было функций, сплошные goto/gosub), соответствующего окружения, также не понимали результат своего труда. Там были тех.дизайнеры, которые за программистов всё придумывали: какие поля должны быть в табличках, какие зависимости входных/выходных данных...
С точки зрения фрагментарности работы программиста микросервисы - такой же инструмент, как и любой другой, который существует для разбиения задачи на подзадачи.
Вообще мне представляется эта история с тенденцией бизнеса перескочить с найма высококвалифицированных разработчиков на дешевых и доступных "студентов" очередным модным течением, которое по-настоящему экономически не обосновано. Слишком многое у нас в обществе сейчас происходит по моде, и масштабного много, так что проблема фрагментарности и мифологичности мышления не только низшее звено работников затрагивает.
Конечно, "нормальная" капиталистическая тенденция должна состоять в том, что благодаря автоматизации труда программиста они - программисты - должны становиться всё более умными и для решения схожих задач должно тратиться меньше программистского труда. Но похоже, что-то пошло не так.
конечно же дело не в них
микросервисы — просто иллюстрация к проблеме
ну а "нормальный" капитализм, увы, не существует и никогда не существовал.
А что нормальное существовало? Коммунизм? :)
да, СССР - это лучший период, причём в истории всего человечества
да, как и у любой реальной вещи, в нем были недостатки, но лучше этого варианта государственного строительства ничего не было
Я не знаю о каком СССР пишите вы. В том СССР, который знаю я, никакого коммунизма не было. Даже на бумаге.
Ну и про "лучший период" может писать либо тролль, либо человек который никогда не жил в СССР. Либо и то и другое вместе.
большой вопрос — что понимать под понятием Коммунизм.
Коммунизм — это идеал, асимптота. Достигнут быть не может. Можно рассуждать лишь о степени приближения.
Так вот, СССР, конечно, включавший в себя море несправедливостей, а всё же стоял ближе всех к самому справедливому обществу на планете.
Социальные лифты были развиты наиболее серьёзно, ни у кого такого не было. Доступ к образованию, медицине — такой, что никому на планете не снилось и не снится.
При этом, да, было что исправлять, что улучшать, как в любой реалистичной системе.
большой вопрос — что понимать под понятием Коммунизм.
Нет никакого большого вопроса. У коммунизма есть конкретное определение. Более того оно было и в СССР. И в СССР же официально считалось что коммунизм не достигнут.
Так вот, СССР, конечно, включавший в себя море несправедливостей, а всё же стоял ближе всех к самому справедливому обществу на планете.
Нет, не стоял. Какие-нибудь скандинавы с их "социальными-солидарными" государствами были к этому гораздо ближе.
«Коммунизм — пробуждение и раскрепощение высших творческих способностей в каждом человеке»
некоторые тупые идиоты измеряют коммунизм по уровням потребления, но это именно удел тупых идиотов.
коммунизм измеряется по реализации творческих способностей. А тут СССР был впереди планеты всей.
PS: Да, интернет позволил появиться таким ресурсам как гитхаб или самиздат, что проявило часть тех самых способностей во многих, однако на момент существования СССР этого всё это отсутствовало где-либо вообще. Потому — не аргумент.
> Нет, не стоял. Какие-нибудь скандинавы с их «социальными-солидарными» государствами были к этому гораздо ближе.
нет не ближе. вы транслируете тупой агитационный штамп.
идите нахуй
некоторые тупые идиоты измеряют коммунизм по уровням потребления, но это именно удел тупых идиотов
Некоторые тупые идиоты придумывают какие-то свои собственные странные определения для существующих понятий. Не надо так.
нет не ближе
Ещё как ближе.
вы транслируете тупой агитационный штамп.
Тупыми агитационными штампами разбрасываетесь тут именно вы. Вы СССР то сами застали? Ну в более-менее сознательном возрасте? Хотя бы в одной скандинавской стране были? Вообще Россию покидали куда-то за исключением отпуска во всяких Турциях-Египтах?
родился и получил образование в нём. Затем, долгое время работал в том что от него осталось — советской а потом российской науке.
да застал
> Ещё как ближе.
ещё раз: с агитками — идите нахуй. рассказывайте своим дебильным деткам, но не тем, кто это застал
родился и получил образование в нём.
Начальное школьное? :)
но не тем, кто это застал
Ну так какие скандинавские страны вы лично "застали" чтобы иметь возможность сравнивать? Где вы в СССР кроме Москвы жили?
высшее. аспирантуру заканчивал уже в условиях рыночной экономики.
> Ну так какие скандинавские страны вы лично «застали» чтобы иметь возможность сравнивать?
скандинавские страны, даже по сравнению с Россией — нищета и голытьба. Плюс победившее разум ЛГБТ. идите нахуй со своими странами
высшее.
Вы в 17 лет получили высшее образование? Зачем врать то?
скандинавские страны
Ну так какие скандинавские страны вы лично «застали» чтобы иметь возможность сравнивать?
идите нахуй
Похоже пора обратиться к @moderator
я поступил в 16 лет и пока получал высшее — сломали СССР. Но оно в те годы почти не менялось: реформаторы занялись высшей школой далеко не сразу (по кр мере в регионах). Поэтому, высшее у меня вполне советское.
> Ну так какие скандинавские страны вы лично «застали» чтобы иметь возможность сравнивать?
если вы считаете что нужно именно «родиться и жить», то тогда сравнивать нельзя вообще ничего.
а в Финляндии (а ещё в Германии, Франции и Турции) я пытался открывать дочку своего бизнеса. так что в этом плане очень близко с ней знаком (найм людей, средние зарплаты итп). в Швеции периодически бывал.
всё — от скандинавии в частности, до евросоюза в целом — крайний депресняк и жить там я бы не хотел ни при каких обстоятельствах.
именно поэтому они войны у нас и разжигают, что им нужно в очередной раз этот накопленный депресняк как-то утилизировать: ЛГБТ уже недостаточно
> Похоже пора обратиться
да велком, в поисках указанного направления, туда тоже часто заходят. Но вам всё же придётся проследовать именно туда, куда направили.
я поступил в 16 лет
То есть высшее образование вы получили не в СССР.
а в Финляндии (а ещё в Германии, Франции и Турции) я пытался открывать дочку своего бизнеса
А сколько дочек своего бизнеса вы открыли в СССР? Ну чтобы было что сравнивать?
всё — от скандинавии в частности, до евросоюза в целом — крайний депресняк и жить там я бы не хотел ни при каких обстоятельствах.
Угу. Никакого сравнения с той же Колымой при СССР...
именно поэтому они войны у нас и разжигают
Они(кто бы этими они не были) Путина контролируют? Не знал.
Микросервисы — отчуждение от результатов труда