У строителей мостов нормирование еще больше чем в софте, однако подите-найдите два одинаковых моста! Требования к ПО - они обычно внешние. Никто не пишет такую подробную спецификацию, чтобы посмотрев на нее два разработчика написали одно и то же. Более того, я вообще люблю участвовать в проектах еще на фазе, когда требования формируются. Ну потому что со своим опытом - я не верю в существование параллельного мира, в котором уже всем ясны и объективно существуют все требования и четкие ТЗ.
Нет, правда - я не знаю где и как вы работаете, но мне вас жаль! И места для творчества у вас нет. И работаете вы только за деньги. И это в программировании - где в отличие от физической обработки материалов (фрезерование, 3д-печать) - нет как таковых ограничений материала и технологии обработки: как вы напишите - так оно и сбудется! А у меня и творчество есть, и работа интересная, да еще и зарплату за это платят. Повезло, наверное! :-)
Вы, наверное, меня с кем-то путаете - не помню чтобы я брал на себя обязательство перед вами отчитываться. Если есть что сказать по теме кроме как зеркалить свою мотивацию (точнее - отсутствие оной) на других людей в профессии - добро пожаловать. А меряться должностями и прочими половыми органами - идите пожалуй в другое место...
Я написал ТС, что если ей для того чтобы высидеть день за клавиатурой - нужно вокруг этого выстроить целую систему (а иначе теряется мотивация) - то она скорее всего ошиблась профессией.
И вы удивитесь, наверное - но у врачей старой школы мотивация была - моя в подметки не годится. Там, понимаете, можно было заразиться - да и помереть случайно. Какие тут деньги ? В гроб их тебе не положат... Однако работали - иногда на износ... Хотя уж в СССР-то точно можно было эти деньги получать за гораздо более спокойную работу!
И еще раз скажу - не меряйте всех по себе. Если вас судьба заставила уголь в шахте долбить, за горнового у домны стоять - ваша интерпретация верна: вы отдаете время и здоровье в обмен на оплату. И конечно же, в свое свободное время вы в шахту не полезете: и пыль, и грязь, и метан может бахнуть...
А привилегия творческой профессии - как раз не различать "работу" и "не работу". И уж во всяком случае не требовать выстраивать систему чтобы способиться высидеть рабочий день!
Эк вас мотает - от необходимости работы до цитирования усатого...
Первое - я с детства занимаюсь программированием, и мне это нравится. Это не значит что я люблю каждый его аспект одинаково. Что-то в моей деятельности мне нравится больше, что-то меньше - но это именно то, чем я хочу заниматься и занимаюсь.
Если мне сейчас за мою работу начать платить один МРОТ - я, конечно же огорчусь, и попробую остаться в професиии сменив проект или работодателя. Ибо мне верится что мы делаем что-то полезное.
Если же окажется что вообще в программировании нигде не платят - значит общество по какой-то причине дает сигнал что на это сейчас нет ресурсов. Значит придется или сменить общество, или заняться чем-то более важным на текущий момент.
И да, я буду расстроен что программирование почему-то стало никому не нужно и больше не оплачивается.
Удивительно, как походя вы проходитесь по мотивации других людей - от пилотов до программистов! Возможно, вам пошло бы на пользу хотя бы теоретически представить что другие люди могут иметь отличные от вас взгляды и мотивацию.
И нет, не всем повезло иметь деньги как гигиенический фактор. Мне трудно представить себе сантехника, который встает утром с радостным предвкушением нырнуть в говно в очередном подвале многоквартирного дома... Однако - инженерная (и интеллектуальная вообще) деятельность - дают ровно такую привилегию: утром вставать в предвкушении нового и интересного рабочего дня... Чего и вам желаю!
Дядя, вы странный! Прочитайте еще раз что я написал ? Какие конкретно слова вам непонятны ? С чего вы взяли что я "дела не делаете, зато все время баловство" ? Ну то есть нет - вы имеете право так считать, но удивительным образом клиенты и работодатели считают иначе... И да, я вас не понимаю. Создается впечатление, что вы могли бы в какой-то другой области успешно и с удовольствием состояться - но по какой-то причине решили себя замучать нелюбимой работой в ИТ...
P.S. За ограбление банка сейчас не вешают - а наоборот, переводят на полное государственное обеспечение. Если ваше ограбление успешно (я имею в виду не только отнять - но и спрятать награбленное) - то ваш доход поделенный на годы отсидки окажется больше зарплаты среднего программиста...
Да. Не факт что прямо на текущую работу - за такие деньги можно и свой бизнес в ИТ завести (хотя и не очень крупный - но все-равно хорошо когда ты можешь сам принимать технические решения, сам за них отвечаешь - и нет странных людей в менеджменте над тобой, которых надо долго и упорно убеждать в том, что надо чистить зубы по утрам и нельзя бесконечно копить технический долг...).
Но представить себе что получив 10 миллионов USD - я начну бесконечно спать и пить чай - мне трудно. Как я офигел с магии программирования (и инженерной деятельности вообще) в 6-7 классе - так и продолжаю...
Что касается философии денег - то я строгий последователь австрийской школы. Если вы работаете с прибылью (то есть из более доступных и малоценных ресурсов производите что-то более редкое и ценное) - значит вы занимаетесь чем-то стоящим. Если же вы берете более ценные ресурсы, и приложив к ним свое умение и старание делаете результат который стоит дешевле - значит общество считает что вы переводите добро на дерьмо, и лучше бы вам перестать...
Однако, если бы моя мотивация была чисто денежной - то мне было бы неважно, работать программистом - или сколотить банду и ограбить банк. Но мне - не всё равно...
Не надо проецировать на других свои проблемы. У меня (и у коллег которых я знаю многие годы) - финансы не мотивирующий, а гигиенический фактор. То есть, без денег мы работать конечно не будем - но работаем точно не из-за них.
Если у вас нет желания работать - значит скорее всего вы заняты не своим делом. Сравните с летчиками - там тоже зарплата приличная, но главная мотивация - летать. И главный страх - что медицина спишет с летной работы (даже если с формальным повышением в должности и приличными деньгами). Собственно, и у меня - сколько лет я не сажусь за монитор - не возникает проблем ни с фокусом, ни с мотивацией... Только с годами недели все быстрее мелькают...
Все так - только наоборот. Новое поколение не имеет мотивации сидеть за компьютером (см заголовок статьи) - и придумывает кучу методик, как этим заниматься.
А мы, олдфаги, ставим таймер чтобы не забыть перерыв сделать...
Тоже около 30 лет в ИТ если считать от первой зарплаты, и около 40 если считать от первой программы на бейсике по самоучителю в УПК...
Удивительны вы - о, новое поколение разработчиков. Помню, на первом 8-битном компьютере - мы с одноклассниками программировали, кинув портфели в угол, глядя на вырвиглазный ч/б телевизор, и только перспектива получения люлей от родителей за невыполненную домашку заставляла нас от программирования оторваться!
Зачем вы вообще в это полезли, если вам для того чтобы за компьютером сидеть - надо "три притопа, два прихлопа..."?!
Генеративный ИИ (LLM) может хорошо делать две вещи: текстовые преобразования - и текстовая имитация любой деятельности. Уровень ИИ - это уровень ребенка в детсаду. Он рисует каляку-маляку, и на серьезных щах вам сообщает: "Это - киска. Вот у нее глазки, вот у нее хвостик!". При этом, ни киски, ни глазок, ни хвостика там и близко нет - потому что слова в детской голове уже выучены, а ума и понимания пока нет.
С учетом громкого разочарования в GPT-5 - очевидно, что переход от слов к глубокому пониманию как минимум серьезно откладывается.
Соответственно - еще раз эмпирическое правило: если какая-то деятельность успешно автоматизируется "ИИ вообще" (aka LLM, aka Semantic Parrot) - значит в ней с самого начала не было смысла, и в идеальном мире можно было вообще не делать (однако в рельности, культурное и политическое давление заставляет хотя бы имитировать деятельность)!
Для того, чтобы удаленка стимулировала расселение - надо сначала сменить модель страны с "метрополия и колонии" на "сеть городов" - как в Европе. Там вы можете жить в Вене (2 млн человек), Братиславе (500 тыс человек), или Гдыне (250 тыс человек) - и качество жизни у вас будет различаться, но не в 10 раз и даже не в 2 раза!
А в РФ - первый дикий скачок случается в момент перехода от Москвы к замкадышам. А второй - когда вы отъезжаете за 30 километров от условного Омска - и оказываетесь на территории которую не иначе как бомбило и грабило НАТО последние 15 лет: развалины ферм, отсутствие нормальных дорог, закрытые ФАП, и далее по-списку...
И в цифрах оно так же выглядит! Количество бюджетных денег на голову население в МСК - 10х от того что есть в регионе. В областном центре! А он соответственно еще в 2-5 раз лучше чем в сельском поселении. Итого, качество жизни отличается в 20-50 раз! Разумеется, удаленка или нет - все стараются скучковаться в нескольких пригодных к жизни локациях...
Из статьи вы должны были правильно понять что надо занести денежку конторе по ИБ которая вам поможет встать в правильную позу и будет подавать вазелин когда вас будут иметь.
На самом деле - с учетом опыта взаимоотношений бизнеса и государства в этой стране - правильная политика (пока вы не выросли в достаточной степени чтобы без труда оплачивать юристов которые будут отбивать наезды проверяющих - или просто закладывать штраф/взятку в цену своих услуг) - уходить в абсолютный отказ. Ваша позиция простая - никаких персональных данных не собираем, не храним и не обрабатываем. Орган сам по себе к вам не придет (какой смысл ему вас искать, когда полно идиотов сами себя в реестре зарегистрировали?!). А даже если придет - то это не уголовное дело, "маски-шоу" и изъятие техники. Они будут писать письма и требровать документы. Ваш ответ: нет, не был, не знаю, не привлекался. Вот почтовый ящик на сайте вашей компании указан! Он никогда не работал, пароля ни у кого нет. Покажите ваше кадровое делопроизводство ? Не знаю о чем вы говорите, бумаги съела кошка, испортил ливень, а потом они еще и сгорели. Можете на заднем дворе у помойки пепел разворошить... Покажите договора с клиентами ? Знать не знаю, может где и были - но сейчас нету. Покажите что у вас в 1С - верите или нет, пароль забыли - сами второй год мучаемся зайти не можем... В худшем случае заплатите штраф за непредоставление документов (а то и его в суде отобъете если правильно отпишетесь) - и от вас отстанут.
А как только вы зарегистрируетесь - вас можно начинать доить. Сначала с вас попросят все политики и реестр того где и что вы храните. А потом каждый раз будет находиться закон/постановление/ведомственная инструкция - которая вот конкретно у вас не выполнена. И каждый раз штраф, время на устранение, оплата конторе за ИБ - устранение, и ждите новую проверку. С учетом дефицита бюджета - штрафов надо собрать много!...
Поделюсь наблюдением - на самом деле, неважно что именно вы внедряете не складе: WMS или новую стеллажную систему. 80% эффекта происходит только потому что начальство оказывается вынуждено потратить -надцать миллионов на склад, и начинает туда ходить и реально контролировать происходящее.
В самом деле - для подавляющего большинства компаний, склад - это центр затрат а не генерации прибыли. Соответственно, отношение к складу - как к нелюбимому ребенку. При этом в положительной фазе экономического цикла никакие преобразования на складе делать нельзя ("Вы что, у нас пик продаж!"), а в отрицательной - хочется, но нет денег...
Соответственно, получается так что все подразделения вокруг (от производства до закупщиков) оптимизируют свою работу (и получают премии за "бери больше, кидай дальше") за счет склада. А склад выживает как может - и до последнего времени, самым дешевым был человеческий ресурс: зачем нужен автоматический паллетёр - трое узбеков с ножницами и рулоном пленки мотают также, а еще в свободное время могут подметать территорию!
И вдруг складом начинает кто-то заниматься, да еще и ресурсы выделяют!...
Эхм, добро пожаловать искать логику в "собачка стоит" но "птичка сидит", "тарелка стоит" но "ложка лежит", и т.д. Или правила чтения в английском... Нет, я не спорю что некая логика есть - и знать ее наверное следует. Но ее имхо проще выявить методом обобщения, когда на интуитивном уровне правила уже известны и используются...
Язык - это довольно хаотичная структура, которая пытается удовлеворить двум совершенно несовместимым требованиям: компактности и помехозащищенности. Компактность требует от языка изменяться так, чтобы наиболее часто выражаемые мысли и понятия - выражались коротко и экономно. Помехозащищенность - требует чтобы вы в критической ситуации на фоне помех, по обрывкам фраз - смогли однозначно установить смысл сказанного.
А поскольку оба этих требования никогда нельзя выполнить одновременно (компактность сокращает хэммингово расстояние между множеством фраз языка, а помехозащищенность - требует его увеличивать) - то язык всегда является кривым компромиссом (или по-научному: парето-оптимальным решением) между ними. Нет большого смысла анализировать правила грамматики (если только вы не работате с родственным языком, грамматика которого вам уже хорошо известна). Большинство правил грамматики могут быть только объяснены задним числом высоколобыми лингвистами - а их честное объяснение: "... так сложилось".
Поэтому не надо заморачиваться формальной грамматикой. Она нужна ровно настолько, чтобы вы смогли начать читать. Это сейчас непопулярно, наверное - но книга известный друг человека! Там вы как раз найдете язык в его живом виде - в ситуациях реальной жизни. Сложно читать взрослую художественную литературу - читайте литературу по специальности, или вообще детские книги. Потом по знакомым уже книгам - слушайте аудиокниги. Потому что важно знать не только как оно пишется, но и как оно слышится. Вообще, язык именно учить - надо в самом начале. Месяца два-три. А потом им надо начинать пользоваться. А если вне уроков вы им не пользуетесь - тогда вообще зачем оно надо?...
Если говорить строго - то компилятор может только гарантировать что в ответ на такую-то конструкцию языка - он вставит в объектный файл такие-то машинные команды. Что произойдет дальше - и упадет ли программа, он не знает и знать не может...
В этом смысле, я вижу три вида конструкций:
Для которых язык предусматривает определенный результат (i++ увеличивает i на 1). И даже если вы работаете на какой-то странной платформе где можно только прибавлять два и вычитать один, то вам придется сделать неэффективную кодогенерацию - но i++ должно увеличить переменную на один, а не на два и не на ноль.
Которые валидны, но язык не может предусмотреть единый для всех результат, т.к. из-за разных аппаратных платформ обеспечить такое единообразие очень дорого. Разъяснения для этих случаев нужно искать в документации на компилятор или машину для которой ведется разработка. Это как раз всякие пограничные случаи, где вы хотите сделать что-то низкоуровневое.
Которые синтаксически валидны, но с точки зрения языка не имеют смысла - это как раз UB.
Первая категория - абсолютно понятна. Это - собственно то, для чего создается переносимый язык. Вторая - тоже понятна. Это то - чего нельзя предусмотреть в языке (если мы настаиваем на компиляции в машинный код). Третья категория мне понятна мало. Особенно - как именно решается: UB это - или implementation defined! И уже совсем мне непонятно - в какой момент (а главное - зачем?!) UB стало пониматься разработчиками компиляторов как карт-бланш на применение любых оптимизаций (из которых самая лучшая - кончено же выкидывание кода из генерации, несмотря на то что программист его в исходном файле буквами написал!)...
Да C++ лучше оставить в стороне - они с кодогенерацией на темплейтах не выживают, если только не применяют оптимизацию: "любой код с UB считается ненаписанным".
Я пытаюсь понять - какие возможности для оптимизации закрывает unaligned access как implementation defined behavior ? Язык программирования С - делался как "переносимый ассемблер". Соответственно, он должен определить подмножество операций, которые гарантированно одинаково выполняются на всех поддерживаемых платформах. А все странности и ограничения платформ - оставьте разработчику компилятора, там наверное разберутся что с этим делать ? А встраивать это как UB прямо в язык (то есть гарантировать что такая конструкция нигде не является корректной и ее можно как хочешь оптимизировать) - я не понимаю...
И вот этого я уже не понимаю. Есть код, который написал разработчик. Задача компилятора - сгенерировать эквивалентный ему машинный код! Это же даже не цикл, где можно вынести инвариант за тело, и сэкономить много машинных тактов. И не assert который можно выключить в продакшн-версии... Если компилятору даются такие широкие права по интерпретации намерений программиста (зачем?!) - надо вводить в язык новое ключевое слово, которое заставляет компилятор сгенерировать код следующего оператора (или блока) "как тут написано": verbatim if(p&1)...)
Вот я не понимаю логику этого решения. Сказать - unaligned access является implementation defined - понимаю. Дальше разработчик компилятора для конкретной платформы должен будет выбрать и задокументировать поведение в такой ситуации, и дальше консистентно его придерживаться. Это никак не ограничивает язык на конкретной платформе, ибо мы не диктуем единственно-правильное поведение (которое действительно на каком-то железе может быть очень дорого, или даже невозможно! реализовать). Например, разработчик компилятора может написать что для int * всегда генерируются машинные команды aligned access. Если там будет невыравненное значение - произойдет прерывание. Или он может добавить платформ-зависимые средства (ключ компиляции, дополнительный атрибут или intrinsic) чтобы сгенерировать медленный но всегда валидный код для unalgned access. Суть в том - что находясь на конкретной платформе - вы можете прочитать как это тут будет работать! И оно так будет работать всегда, а если изменится - то опять же об этом будет написано в документации.
А UB - это очень сильное утверждение: так никогда не может быть. И поэтому код с UB эквивалентен любому другому куску кода (в том числе пустому)... И дальше начинаются странные оптимизации, когда от изменения одного символа в исходном коде - у вас из объектного файла пропадает половина программы... Опять-таки, это больше бочка в сторону C++, а C был всегда более консервативен - и компилировал то, что программист написал, а не "абстрактную программу которая эквивалентна написанному программистом, но только лучше" (c). Плюс - что происходит с кодом UB - нигде не документируется, и компилятор может (формально - оставаясь той же версии) сегодня компилировать так, а завтра - этак...
И я не понимаю - с какой целью это сделано ? Тяжелое наследие гонок компиляторов за наносекундами в бенчмарках ?
Вопрос - а почему это именно Undefined, а не Implementation Defined Behavior ?! В существующей трактовке (правда, этим славятся C++ компиляторы - в C это не так явно выражено) - UB это снятие любых тормозов компилятора, и возможность приписать коду с UB любые свойства, удобные для дальнейшей оптимизации. Опять же, C++ предпочитает в силу тяжелой судьбы оптимизировать код методом удаления - поэтому код с UB обычно приводит к исчезновению целых кусков того, что вы написали в исходнике...
ИМХО тут в чистом виде Implementation Defined, а не UB. Конструкция легальная, код должен быть сгенерирован - а уж сработает он или нет - читайте руководство к своему компилятору и процессору...
У строителей мостов нормирование еще больше чем в софте, однако подите-найдите два одинаковых моста! Требования к ПО - они обычно внешние. Никто не пишет такую подробную спецификацию, чтобы посмотрев на нее два разработчика написали одно и то же. Более того, я вообще люблю участвовать в проектах еще на фазе, когда требования формируются. Ну потому что со своим опытом - я не верю в существование параллельного мира, в котором уже всем ясны и объективно существуют все требования и четкие ТЗ.
Нет, правда - я не знаю где и как вы работаете, но мне вас жаль! И места для творчества у вас нет. И работаете вы только за деньги. И это в программировании - где в отличие от физической обработки материалов (фрезерование, 3д-печать) - нет как таковых ограничений материала и технологии обработки: как вы напишите - так оно и сбудется! А у меня и творчество есть, и работа интересная, да еще и зарплату за это платят. Повезло, наверное! :-)
Вы, наверное, меня с кем-то путаете - не помню чтобы я брал на себя обязательство перед вами отчитываться. Если есть что сказать по теме кроме как зеркалить свою мотивацию (точнее - отсутствие оной) на других людей в профессии - добро пожаловать. А меряться должностями и прочими половыми органами - идите пожалуй в другое место...
Я написал ТС, что если ей для того чтобы высидеть день за клавиатурой - нужно вокруг этого выстроить целую систему (а иначе теряется мотивация) - то она скорее всего ошиблась профессией.
И вы удивитесь, наверное - но у врачей старой школы мотивация была - моя в подметки не годится. Там, понимаете, можно было заразиться - да и помереть случайно. Какие тут деньги ? В гроб их тебе не положат... Однако работали - иногда на износ... Хотя уж в СССР-то точно можно было эти деньги получать за гораздо более спокойную работу!
И еще раз скажу - не меряйте всех по себе. Если вас судьба заставила уголь в шахте долбить, за горнового у домны стоять - ваша интерпретация верна: вы отдаете время и здоровье в обмен на оплату. И конечно же, в свое свободное время вы в шахту не полезете: и пыль, и грязь, и метан может бахнуть...
А привилегия творческой профессии - как раз не различать "работу" и "не работу". И уж во всяком случае не требовать выстраивать систему чтобы способиться высидеть рабочий день!
Эк вас мотает - от необходимости работы до цитирования усатого...
Первое - я с детства занимаюсь программированием, и мне это нравится. Это не значит что я люблю каждый его аспект одинаково. Что-то в моей деятельности мне нравится больше, что-то меньше - но это именно то, чем я хочу заниматься и занимаюсь.
Если мне сейчас за мою работу начать платить один МРОТ - я, конечно же огорчусь, и попробую остаться в професиии сменив проект или работодателя. Ибо мне верится что мы делаем что-то полезное.
Если же окажется что вообще в программировании нигде не платят - значит общество по какой-то причине дает сигнал что на это сейчас нет ресурсов. Значит придется или сменить общество, или заняться чем-то более важным на текущий момент.
И да, я буду расстроен что программирование почему-то стало никому не нужно и больше не оплачивается.
Удивительно, как походя вы проходитесь по мотивации других людей - от пилотов до программистов! Возможно, вам пошло бы на пользу хотя бы теоретически представить что другие люди могут иметь отличные от вас взгляды и мотивацию.
И нет, не всем повезло иметь деньги как гигиенический фактор. Мне трудно представить себе сантехника, который встает утром с радостным предвкушением нырнуть в говно в очередном подвале многоквартирного дома... Однако - инженерная (и интеллектуальная вообще) деятельность - дают ровно такую привилегию: утром вставать в предвкушении нового и интересного рабочего дня... Чего и вам желаю!
Дядя, вы странный! Прочитайте еще раз что я написал ? Какие конкретно слова вам непонятны ? С чего вы взяли что я "дела не делаете, зато все время баловство" ? Ну то есть нет - вы имеете право так считать, но удивительным образом клиенты и работодатели считают иначе... И да, я вас не понимаю. Создается впечатление, что вы могли бы в какой-то другой области успешно и с удовольствием состояться - но по какой-то причине решили себя замучать нелюбимой работой в ИТ...
P.S. За ограбление банка сейчас не вешают - а наоборот, переводят на полное государственное обеспечение. Если ваше ограбление успешно (я имею в виду не только отнять - но и спрятать награбленное) - то ваш доход поделенный на годы отсидки окажется больше зарплаты среднего программиста...
Да. Не факт что прямо на текущую работу - за такие деньги можно и свой бизнес в ИТ завести (хотя и не очень крупный - но все-равно хорошо когда ты можешь сам принимать технические решения, сам за них отвечаешь - и нет странных людей в менеджменте над тобой, которых надо долго и упорно убеждать в том, что надо чистить зубы по утрам и нельзя бесконечно копить технический долг...).
Но представить себе что получив 10 миллионов USD - я начну бесконечно спать и пить чай - мне трудно. Как я офигел с магии программирования (и инженерной деятельности вообще) в 6-7 классе - так и продолжаю...
Что касается философии денег - то я строгий последователь австрийской школы. Если вы работаете с прибылью (то есть из более доступных и малоценных ресурсов производите что-то более редкое и ценное) - значит вы занимаетесь чем-то стоящим. Если же вы берете более ценные ресурсы, и приложив к ним свое умение и старание делаете результат который стоит дешевле - значит общество считает что вы переводите добро на дерьмо, и лучше бы вам перестать...
Однако, если бы моя мотивация была чисто денежной - то мне было бы неважно, работать программистом - или сколотить банду и ограбить банк. Но мне - не всё равно...
Не надо проецировать на других свои проблемы. У меня (и у коллег которых я знаю многие годы) - финансы не мотивирующий, а гигиенический фактор. То есть, без денег мы работать конечно не будем - но работаем точно не из-за них.
Если у вас нет желания работать - значит скорее всего вы заняты не своим делом. Сравните с летчиками - там тоже зарплата приличная, но главная мотивация - летать. И главный страх - что медицина спишет с летной работы (даже если с формальным повышением в должности и приличными деньгами). Собственно, и у меня - сколько лет я не сажусь за монитор - не возникает проблем ни с фокусом, ни с мотивацией... Только с годами недели все быстрее мелькают...
Все так - только наоборот. Новое поколение не имеет мотивации сидеть за компьютером (см заголовок статьи) - и придумывает кучу методик, как этим заниматься.
А мы, олдфаги, ставим таймер чтобы не забыть перерыв сделать...
Тоже около 30 лет в ИТ если считать от первой зарплаты, и около 40 если считать от первой программы на бейсике по самоучителю в УПК...
Удивительны вы - о, новое поколение разработчиков. Помню, на первом 8-битном компьютере - мы с одноклассниками программировали, кинув портфели в угол, глядя на вырвиглазный ч/б телевизор, и только перспектива получения люлей от родителей за невыполненную домашку заставляла нас от программирования оторваться!
Зачем вы вообще в это полезли, если вам для того чтобы за компьютером сидеть - надо "три притопа, два прихлопа..."?!
Генеративный ИИ (LLM) может хорошо делать две вещи: текстовые преобразования - и текстовая имитация любой деятельности. Уровень ИИ - это уровень ребенка в детсаду. Он рисует каляку-маляку, и на серьезных щах вам сообщает: "Это - киска. Вот у нее глазки, вот у нее хвостик!". При этом, ни киски, ни глазок, ни хвостика там и близко нет - потому что слова в детской голове уже выучены, а ума и понимания пока нет.
С учетом громкого разочарования в GPT-5 - очевидно, что переход от слов к глубокому пониманию как минимум серьезно откладывается.
Соответственно - еще раз эмпирическое правило: если какая-то деятельность успешно автоматизируется "ИИ вообще" (aka LLM, aka Semantic Parrot) - значит в ней с самого начала не было смысла, и в идеальном мире можно было вообще не делать (однако в рельности, культурное и политическое давление заставляет хотя бы имитировать деятельность)!
Для того, чтобы удаленка стимулировала расселение - надо сначала сменить модель страны с "метрополия и колонии" на "сеть городов" - как в Европе. Там вы можете жить в Вене (2 млн человек), Братиславе (500 тыс человек), или Гдыне (250 тыс человек) - и качество жизни у вас будет различаться, но не в 10 раз и даже не в 2 раза!
А в РФ - первый дикий скачок случается в момент перехода от Москвы к замкадышам. А второй - когда вы отъезжаете за 30 километров от условного Омска - и оказываетесь на территории которую не иначе как бомбило и грабило НАТО последние 15 лет: развалины ферм, отсутствие нормальных дорог, закрытые ФАП, и далее по-списку...
И в цифрах оно так же выглядит! Количество бюджетных денег на голову население в МСК - 10х от того что есть в регионе. В областном центре! А он соответственно еще в 2-5 раз лучше чем в сельском поселении. Итого, качество жизни отличается в 20-50 раз! Разумеется, удаленка или нет - все стараются скучковаться в нескольких пригодных к жизни локациях...
Из статьи вы должны были правильно понять что надо занести денежку конторе по ИБ которая вам поможет встать в правильную позу и будет подавать вазелин когда вас будут иметь.
На самом деле - с учетом опыта взаимоотношений бизнеса и государства в этой стране - правильная политика (пока вы не выросли в достаточной степени чтобы без труда оплачивать юристов которые будут отбивать наезды проверяющих - или просто закладывать штраф/взятку в цену своих услуг) - уходить в абсолютный отказ. Ваша позиция простая - никаких персональных данных не собираем, не храним и не обрабатываем. Орган сам по себе к вам не придет (какой смысл ему вас искать, когда полно идиотов сами себя в реестре зарегистрировали?!). А даже если придет - то это не уголовное дело, "маски-шоу" и изъятие техники. Они будут писать письма и требровать документы. Ваш ответ: нет, не был, не знаю, не привлекался. Вот почтовый ящик на сайте вашей компании указан! Он никогда не работал, пароля ни у кого нет. Покажите ваше кадровое делопроизводство ? Не знаю о чем вы говорите, бумаги съела кошка, испортил ливень, а потом они еще и сгорели. Можете на заднем дворе у помойки пепел разворошить... Покажите договора с клиентами ? Знать не знаю, может где и были - но сейчас нету. Покажите что у вас в 1С - верите или нет, пароль забыли - сами второй год мучаемся зайти не можем... В худшем случае заплатите штраф за непредоставление документов (а то и его в суде отобъете если правильно отпишетесь) - и от вас отстанут.
А как только вы зарегистрируетесь - вас можно начинать доить. Сначала с вас попросят все политики и реестр того где и что вы храните. А потом каждый раз будет находиться закон/постановление/ведомственная инструкция - которая вот конкретно у вас не выполнена. И каждый раз штраф, время на устранение, оплата конторе за ИБ - устранение, и ждите новую проверку. С учетом дефицита бюджета - штрафов надо собрать много!...
Поделюсь наблюдением - на самом деле, неважно что именно вы внедряете не складе: WMS или новую стеллажную систему. 80% эффекта происходит только потому что начальство оказывается вынуждено потратить -надцать миллионов на склад, и начинает туда ходить и реально контролировать происходящее.
В самом деле - для подавляющего большинства компаний, склад - это центр затрат а не генерации прибыли. Соответственно, отношение к складу - как к нелюбимому ребенку. При этом в положительной фазе экономического цикла никакие преобразования на складе делать нельзя ("Вы что, у нас пик продаж!"), а в отрицательной - хочется, но нет денег...
Соответственно, получается так что все подразделения вокруг (от производства до закупщиков) оптимизируют свою работу (и получают премии за "бери больше, кидай дальше") за счет склада. А склад выживает как может - и до последнего времени, самым дешевым был человеческий ресурс: зачем нужен автоматический паллетёр - трое узбеков с ножницами и рулоном пленки мотают также, а еще в свободное время могут подметать территорию!
И вдруг складом начинает кто-то заниматься, да еще и ресурсы выделяют!...
Эхм, добро пожаловать искать логику в "собачка стоит" но "птичка сидит", "тарелка стоит" но "ложка лежит", и т.д. Или правила чтения в английском... Нет, я не спорю что некая логика есть - и знать ее наверное следует. Но ее имхо проще выявить методом обобщения, когда на интуитивном уровне правила уже известны и используются...
Язык - это довольно хаотичная структура, которая пытается удовлеворить двум совершенно несовместимым требованиям: компактности и помехозащищенности. Компактность требует от языка изменяться так, чтобы наиболее часто выражаемые мысли и понятия - выражались коротко и экономно. Помехозащищенность - требует чтобы вы в критической ситуации на фоне помех, по обрывкам фраз - смогли однозначно установить смысл сказанного.
А поскольку оба этих требования никогда нельзя выполнить одновременно (компактность сокращает хэммингово расстояние между множеством фраз языка, а помехозащищенность - требует его увеличивать) - то язык всегда является кривым компромиссом (или по-научному: парето-оптимальным решением) между ними. Нет большого смысла анализировать правила грамматики (если только вы не работате с родственным языком, грамматика которого вам уже хорошо известна). Большинство правил грамматики могут быть только объяснены задним числом высоколобыми лингвистами - а их честное объяснение: "... так сложилось".
Поэтому не надо заморачиваться формальной грамматикой. Она нужна ровно настолько, чтобы вы смогли начать читать. Это сейчас непопулярно, наверное - но книга известный друг человека! Там вы как раз найдете язык в его живом виде - в ситуациях реальной жизни. Сложно читать взрослую художественную литературу - читайте литературу по специальности, или вообще детские книги. Потом по знакомым уже книгам - слушайте аудиокниги. Потому что важно знать не только как оно пишется, но и как оно слышится. Вообще, язык именно учить - надо в самом начале. Месяца два-три. А потом им надо начинать пользоваться. А если вне уроков вы им не пользуетесь - тогда вообще зачем оно надо?...
Если говорить строго - то компилятор может только гарантировать что в ответ на такую-то конструкцию языка - он вставит в объектный файл такие-то машинные команды. Что произойдет дальше - и упадет ли программа, он не знает и знать не может...
В этом смысле, я вижу три вида конструкций:
Для которых язык предусматривает определенный результат (i++ увеличивает i на 1). И даже если вы работаете на какой-то странной платформе где можно только прибавлять два и вычитать один, то вам придется сделать неэффективную кодогенерацию - но i++ должно увеличить переменную на один, а не на два и не на ноль.
Которые валидны, но язык не может предусмотреть единый для всех результат, т.к. из-за разных аппаратных платформ обеспечить такое единообразие очень дорого. Разъяснения для этих случаев нужно искать в документации на компилятор или машину для которой ведется разработка. Это как раз всякие пограничные случаи, где вы хотите сделать что-то низкоуровневое.
Которые синтаксически валидны, но с точки зрения языка не имеют смысла - это как раз UB.
Первая категория - абсолютно понятна. Это - собственно то, для чего создается переносимый язык. Вторая - тоже понятна. Это то - чего нельзя предусмотреть в языке (если мы настаиваем на компиляции в машинный код). Третья категория мне понятна мало. Особенно - как именно решается: UB это - или implementation defined! И уже совсем мне непонятно - в какой момент (а главное - зачем?!) UB стало пониматься разработчиками компиляторов как карт-бланш на применение любых оптимизаций (из которых самая лучшая - кончено же выкидывание кода из генерации, несмотря на то что программист его в исходном файле буквами написал!)...
Да C++ лучше оставить в стороне - они с кодогенерацией на темплейтах не выживают, если только не применяют оптимизацию: "любой код с UB считается ненаписанным".
Я пытаюсь понять - какие возможности для оптимизации закрывает unaligned access как implementation defined behavior ? Язык программирования С - делался как "переносимый ассемблер". Соответственно, он должен определить подмножество операций, которые гарантированно одинаково выполняются на всех поддерживаемых платформах. А все странности и ограничения платформ - оставьте разработчику компилятора, там наверное разберутся что с этим делать ? А встраивать это как UB прямо в язык (то есть гарантировать что такая конструкция нигде не является корректной и ее можно как хочешь оптимизировать) - я не понимаю...
И вот этого я уже не понимаю. Есть код, который написал разработчик. Задача компилятора - сгенерировать эквивалентный ему машинный код! Это же даже не цикл, где можно вынести инвариант за тело, и сэкономить много машинных тактов. И не assert который можно выключить в продакшн-версии... Если компилятору даются такие широкие права по интерпретации намерений программиста (зачем?!) - надо вводить в язык новое ключевое слово, которое заставляет компилятор сгенерировать код следующего оператора (или блока) "как тут написано": verbatim if(p&1)...)
Вот я не понимаю логику этого решения. Сказать - unaligned access является implementation defined - понимаю. Дальше разработчик компилятора для конкретной платформы должен будет выбрать и задокументировать поведение в такой ситуации, и дальше консистентно его придерживаться. Это никак не ограничивает язык на конкретной платформе, ибо мы не диктуем единственно-правильное поведение (которое действительно на каком-то железе может быть очень дорого, или даже невозможно! реализовать). Например, разработчик компилятора может написать что для int * всегда генерируются машинные команды aligned access. Если там будет невыравненное значение - произойдет прерывание. Или он может добавить платформ-зависимые средства (ключ компиляции, дополнительный атрибут или intrinsic) чтобы сгенерировать медленный но всегда валидный код для unalgned access. Суть в том - что находясь на конкретной платформе - вы можете прочитать как это тут будет работать! И оно так будет работать всегда, а если изменится - то опять же об этом будет написано в документации.
А UB - это очень сильное утверждение: так никогда не может быть. И поэтому код с UB эквивалентен любому другому куску кода (в том числе пустому)... И дальше начинаются странные оптимизации, когда от изменения одного символа в исходном коде - у вас из объектного файла пропадает половина программы... Опять-таки, это больше бочка в сторону C++, а C был всегда более консервативен - и компилировал то, что программист написал, а не "абстрактную программу которая эквивалентна написанному программистом, но только лучше" (c). Плюс - что происходит с кодом UB - нигде не документируется, и компилятор может (формально - оставаясь той же версии) сегодня компилировать так, а завтра - этак...
И я не понимаю - с какой целью это сделано ? Тяжелое наследие гонок компиляторов за наносекундами в бенчмарках ?
Вопрос - а почему это именно Undefined, а не Implementation Defined Behavior ?! В существующей трактовке (правда, этим славятся C++ компиляторы - в C это не так явно выражено) - UB это снятие любых тормозов компилятора, и возможность приписать коду с UB любые свойства, удобные для дальнейшей оптимизации. Опять же, C++ предпочитает в силу тяжелой судьбы оптимизировать код методом удаления - поэтому код с UB обычно приводит к исчезновению целых кусков того, что вы написали в исходнике...
ИМХО тут в чистом виде Implementation Defined, а не UB. Конструкция легальная, код должен быть сгенерирован - а уж сработает он или нет - читайте руководство к своему компилятору и процессору...