Для этого насколько помню всё равно появляется поле, содержащее то что прямо попадает под критерий - телефон или мейл, хотя, если сам сайт сначала открывает фрейм с формой ЕСИА то мяч уже на стороне этой системы и формально вроде как сайт не попадает под эти ограничения, тут уже вопрос интереснее, является ли другой домен частью сайта, если он визуально содержит форму ввода персональных данных на фоне основного. В случае же хеша - вводится одноразово сгенерированный код для копиаста или QR. С ещё одной стороны - сайт даёт этот куаркод который потом аутентифицируется с сессии телефона. Формально он также содержит двоичник не содержащий персоналки.
Но ведь вывод ассемблера может быть совершенно разный при включённой оптимизации, её опциях, версии компилятора итд, то есть сборка должна подразумевать точное соответствие всех ключей, быть может даже и сторонних либ, с опцией -O3 можно получить что угодно
Для языка, претендующего как инструмент общего назначения, самый лучший тест - это написать компилятор/интерпретатор Дракона на самом Драконе. Так называемые Self-Hosting языки. Тем более что здесь первично фактически абстрактное синтаксическое дерево (JSON для этого мало подходит из-за проблемы циклических ссылок) и алгоритм. Скорее для обучения ИИ больше подойдёт описание проверяемой последовательности действий или непосредственно абстрактного синтаксического дерева.
Насколько помню можно было запускать на 386м Windows 3.11, который умел уже делать помимо EMM файл подкачки, тем самым формируя виртуальную память больше чем физическую, поэтому свернув окно до 160x100 пикселей (была такая опция, не помню хоткей) можно было вполне запустить и на 2 МБ в DOS-сессии командной строки.
А что если будет некий платный сервис для разработчиков, который будет содержать хранилище персональных данных оформленное полностью в соответствии с РКН и предоставлять хеши пользователя (может даже одноразовые для сессии, истребуемые движком целевого сайта). И те, кто не хочет лишний раз связываться с этими процедурами могут просто запросить в форме "введите ваш ORCID ID, SPIN-код РИНЦ" для прохождения регистрации. В принципе даже пароль не нужен и какие-либо скрипты. Персональные данные вытягиваются из официальной базы данных с которой уже подписан договор о предоставлении таких услуг, а сами согласия об обработки пользователь уже подписывает хоть по ЭЦП с этой третьей организацией.
Microsoft хороши тем, что они очень хорошо дружат с производителями железа. Скорее всего и так понятно что домашний комп или рабочая станция это фактически уже тонкий клиент и без инета скорее можно использовать как большую ардуину. Рабочие станции энтерпрайз это другая история для CAD/CAM/дизайна и там уже винда идёт корпоративная. Вообщем вполне разумное с точки зрения бизнеса решение и скорее всего путём взаимодействия с теми кто делает процы и чипсеты могут закрыть лазейки и для опенсоурса, когда будет исполняться подписанный код или даже эффективно исполняться то, что под винду, и тормозить под другие ОС, так как не будут использоваться каких-либо специализированные фишки, свойственные только майкам для внешних контроллеров (GPU, звук, диски, порты), таких узких мест на самом деле очень много.
Важен вопрос самого обучения, который представляется как некая задача оптимизации по заданному критерию. Так вот в течении жизни происходит нахождение как критериев так и поиск оптимума и чем дальше тем больше всё скатывается до некоего глобального минимума, который устраивает и отвечает требованиям характера, привычек, поведения, взаимодействия. Методы самой оптимизации можно поменять легко, это опыт, а вот критерий - это сугубо индивидуальное. Для кого-то уникальные 10 строк кода - это супер, для другого - 10 пойманных многоклеточных на обед - достижение, и то и другое, грубо говоря, стратегия поиска комфортных условий обитания (в противовес "дарвинизму" о борьбе за выживание)
имеется в виду разумных инопланетян. Вот представьте, приходит к Вам на работу некто, который имеет дискету с решением всех Ваших задач на 10 лет вперёд, векторные схемы, эскизы, формулы, отчёты, к кому позвонить, у кого заказать. Уверяю, 1,44 МБ сжатых данных для ключевых аспектов деятельности за это время более чем достаточно (в этом плане некто прав, что и 640 кБ хватит всем). По всем критериям этот некто - инопланетное существо. А по факту вскоре это будет ИИ.
1/10 c это уже скорости, на которых уже возможен полноценный термоядерный синтез, например для микстуры дейтерий-тритий оптимум, соответствующий паре десятков килоэлектронвольт это 1% от скорости света. То есть любая прилетевшая "молекула" в космический аппарат уже может не то что выбивать из оболочки всё что можно но и вступать со всем этим делом в ядерные реакции. Единственный возможный вариант - вызвать локальное прерывание в компьютере, моделирующим нашу Вселенную. Вообщем программная точка останова наподобие ловушки IRQ 3, осталось её только найти методом подбора, далее подменить стек пространства-времени и сделать return уже в другой точке адреса возврата.
Гораздо более захватывающая история - это диффузия за миллиарды лет углекислоты, воды и прочих активных веществ в металлы. Этакая космическая ржавчина. Хотя если посчитать среднюю плотность водородной плазмы как десяток атомов на кубометр (даже если это нейтральные молекулы, на скоростях десяток км/с имеют эффективную температуру в тысячи град, очень грубо - формула тепловой скорости √3kT/m), то за миллиард лет с этим водородом прореагирует лишь 1 см поверхности кометы. Однако, при прохождении плотных облаков, остатков сверхновых там может быть другая ситуация. Поэтому такие путешествия вбирают в себя историю как годовые кольца на деревьях, выглядит это как плазмохимическая обработка но практически без объёмного нагрева поверхности, которая нагрета чуть больше чем реликтовое излучение. Но если она проходит рядом со звездой запускаются совсем иные механизмы, связанные с теплом. И вот эта вся накопленная за эти "годы" (невероятно представить, что это от начала Архея до человека) химия начинает сублимировать
Точно! Поторопился с квадратом, это для массы. Действительно и , следовательно относительный радиус растёт как , как раз . Примерно тоже самое относится и к ядерным взрывам, диаметр fireball от мегатонн и давнишние споры о величине Тунгусского метеорита, хотя если он состоял из воды, она вполне могла на таких скоростях сначала превратиться в плазму, диссоциировать на микс водород-кислород а потом опять "сгореть" до воды.
Обычная скорость объектов из пояса астероидов до 20 км/с при столкновении, из облака Оорта под 50, здесь же при ускорении Солнцем может быть и все 100. Так что 5 км согласно легко превращаются в 25. Так что достаточно небольшой межзвёздный метеорит может вызвать последствия, завершившие эволюцию не птичьих динозавров.
Совершенно верно. В этой концепции в принципе нет разделения на тип хранилища объектов. Это может быть облако сервер:порт, сайт https, запрос к БД, к диску C: или по UART к контроллеру. Система управления версий изначально была заточена под управление именно файлами а не непосредственно программными элементами. В этом и есть главная беда. Потенциально в новых подходах указывается источник данных и необходимые атрибуты, такие как версия, хеш, дата, некое имя/ID (например, обозначающее ветку), и указывается для конкретно того что нужно - пространства имён, функции или класса. Нет смысла тянуть файл который на усмотрение разработчиков может содержать пиктограммку в Base64 просто потому что так захотелось. Также на уровне линковки в elf/so/dll уже давным давно должны появиться атрибуты версий объектов, идентификаторы, контрольные суммы. Поэтому посреди бинарников всегда можно выбрать только то что необходимо а не дублировать всё по папкам или релизить вместе с программой, также это позволяет инкапсулировать то что является условно read-only как системная библиотека, что-то в локалях у пользователя что-то вместе с программой. Указывая эти идентификаторы практически полностью можно исключить ошибки линковки при встрече двух файлов, т к. линкёр уже будет знать что именно из них вытягивать, в противном случае надо играться с path который будет показывать откуда что брать, это вечная проблема когда необходимо держать локальный зоопарк из нескольких версий. Более того, если в объектнике, формат которого не менялся с середины 80-х будут уже более современные атрибуты, связанные с управлением версиями а не просто 64 бит этикетка, их можно объединять и укрупнять а имя файла или либы уже значения иметь не будет, содержимое может быть индексировано уже на уровне ОС, плюс взаимосвязь с объектами включения, чтобы заголовочники были также синхронизированы с dll/so (это отдельная боль), в этом случае добавляется инструкция с идентификатором, позволяющая точно согласовать версию заголовочника и двоичника.
Так все новые фичи для компилятора могут быть инициированы как внутри исходника, например, какой-либо прагмой зависящей от версии а также явным указанием. Например gcc поддерживает опции -std=c23 или что-то вроде -std=iso9899:2023. При компиляции можно указать какой именно стандарт и расширение использовать. Вообщем в любом случае все эти свистки командной строки должны уйти внутрь кода и самого языка и убрать файл как структурную единицу проекта, это ведь просто именованная запись а не сам код так сказать. Иными словами проблему путей, линковок, зависимостей, символических ссылок, всяких copy/rm/ls и прочих песен с файлопапками искоренить на уровне идентификаторов и пространств имён в самом языке. Компилятор будет понимать файлы и подкаталоги как единое целое, но внутри вполне всё может быть разбито на проекты, например, ключевым словом project, нечто вроде архива, производить индексацию библиотек, синхронизацию итд. Вообщем это уже комбайн для сборки, но один, без распыления на отдельные утилиты со своими капризами и запросами. То есть меняется мировоззрение по самому представлению проекта уже вне файловой системы на языке предметной области. Конечно все привыкли к тому чему учили, но это не может уже продолжаться полвека.
Механизм Enter-Exit создаёт блокировку "прерываний" внутри процесса, это выглядит как некий аналог GIL или Enable/Disable interrupt в контроллере или Enter/LeaveCriticalSection, поэтому, должна быть гарантия что внутри этого процесса код будет выполнен за фиксированное время и не возникнет таймаутов. Чистое многопроцессорное (не просто многопоточное) исполнение позволяет делать некий эквивалент вложенных прерываний. Поэтому конечно хотелось бы чтобы общение с процессом шло через FIFO или SharedMemory (с управлением оной), это позволит избежать дублирования внешних стеков данных, которые должны как-то ещё обрабатывать критические секции (привет всевозможным флажкам состояний) особенно если там динамическая аллокация памяти без специальных Interprocess-средств и управление кучей.
Интересно, в принципе в зависимостях более чем достаточно для GUI всяческих libGL*, но зачем там столько дополнительных libX11 (GLX), а как же Wayland, который EGL? Хотя вроде как Mesa тоже имеется.
Вот, потихоньку всё начинает приходить к общему знаменателю, который ещё вывел Ван Россум для Python-а в далёком 91м году на основе ОС Амёба. Там в конце довольно интересная публикация от 88 года на предмет Parallel make. Так вот тогда ещё предполагалось что среда разработки и язык могут стать единым целым и помогать друг другу. Это к вопросу к табуляциям которые фактически и являются атрибутами вложенности и области видимости. Также можно было бы точно такие же фичи сделать для комментариев и иных вещей. Вообщем спустя 40 лет похоже будет очередной виток.
Feb1991: X\Python\ does not (yet!) provide an intelligent input line editing
Xfacility, so you have to type a tab or space(s) for each indented line.
XIn practice you will prepare more complicated input for \Python\ with a
Это уже другой вопрос что сложность понимания кода дополняется сложностью понимания вспомогательных инструментов - помимо языка надо знать bash/bat/git/флажки компилятора, различные прагмы-макросы, непосредственно make-языки. Иными словами количество вбираемой информации не изменится если её часть переместится внутрь языка и станет его атрибутом, то есть можно использовать можно нет. Ну это как С++ вместо ООП и прочего синтаксического сахара можно вполне использовать как С с классами или просто как процедурный. Бывало даже видел программы состоящие прямиком из asm-вставок, компилятор нужен был только для аргументов функции и возврата. Поэтому код, который удобно отлаживать, делать опции при сборке для тех или иных компонент кода, а не файлов, будет гораздо лучше чем если это дело отдельно отдать управлять внешним инструментом который просто сложился исторически а не был создан изначально, плюс набегают ошибки, когда действие делается не одним инструментом а двумя и более, много синхронизируемых сущностей, там один флажок, здесь другой, там имя файла не совпадает там ещё что-то, часовой пояс поменяли до уровня up to date, переменную среды не прописали, path не туда. То есть за кодом тянется дополнительная вереница исключительно системных дел. Если это уйдёт в код то он станет самособираемым и практически исчезнет необходимость во внешнем инструменте. Там на самом деле не так много необходимо будет выучить. Думаю ключевых слов version, debug, link, map, control, request, exclude, update, hash, options, optimize, code_id, testfunc и что то в этом роде будет не так много, которые практически полностью позволят настроить как и что собирать если что-то не нравится по умолчанию. Движение на этот счёт имеется в виде танцев с бубном но как-то слабо из за гигантского легаси и разросшихся вспомогательных инструментов, что пора бы уже комитету C++26 уже сделать более дружелюбным к системам сборки и версионирования наравне с другими языками.
Именно так. Что изменение коммента не есть изменение кода что не нужно перекомпилировать весь мир или обходить это с использованием иных абстракций. То есть в самом коде начинают присутствовать элементы версий, git, контрольные суммы, даты/дескрипторы создания, модификаций функций и классов, включая всевозможные фичи для отладки вроде лишних assertion, опций оптимизации конкретного фрагмента кода начиная от -O0 и заканчивая -O3, когда необходимо отладить только вот какой-то конкретный кусочек функции без её вытаскивания в отдельный файл, прагмы станут уже нормальными опциями для статического динамического размещения, map/ld-файл уже как-то ближе к коду а не отдельная сущность, включая настройки, нормальные унифицированные интрисики как стандартное расширение языка и многие другие фишки. Вообщем система сборки должна уже давным давно проникнуть внутрь компилятора и стать его частью а не костылём снаружи, включая управление precompiled headers, опций изменений, макрорасширений/шаблонов, внешние ссылки на линковку по идентификаторам а не по файловой мешанине, избежать дублирование зависимостей итд итп.
Для эмбеддера если нет пина для подключения осциллографа, особенно петельки для земли из печатной платы, то это уже не отладочный комплект. Если по бокам был бы угловой PLD со всей периферией, расфасованной по функциям а не по номеру GPIO, то отлично, если с другого бока JTAG - вдвойне.
Для этого насколько помню всё равно появляется поле, содержащее то что прямо попадает под критерий - телефон или мейл, хотя, если сам сайт сначала открывает фрейм с формой ЕСИА то мяч уже на стороне этой системы и формально вроде как сайт не попадает под эти ограничения, тут уже вопрос интереснее, является ли другой домен частью сайта, если он визуально содержит форму ввода персональных данных на фоне основного. В случае же хеша - вводится одноразово сгенерированный код для копиаста или QR. С ещё одной стороны - сайт даёт этот куаркод который потом аутентифицируется с сессии телефона. Формально он также содержит двоичник не содержащий персоналки.
Но ведь вывод ассемблера может быть совершенно разный при включённой оптимизации, её опциях, версии компилятора итд, то есть сборка должна подразумевать точное соответствие всех ключей, быть может даже и сторонних либ, с опцией -O3 можно получить что угодно
Для языка, претендующего как инструмент общего назначения, самый лучший тест - это написать компилятор/интерпретатор Дракона на самом Драконе. Так называемые Self-Hosting языки. Тем более что здесь первично фактически абстрактное синтаксическое дерево (JSON для этого мало подходит из-за проблемы циклических ссылок) и алгоритм. Скорее для обучения ИИ больше подойдёт описание проверяемой последовательности действий или непосредственно абстрактного синтаксического дерева.
Насколько помню можно было запускать на 386м Windows 3.11, который умел уже делать помимо EMM файл подкачки, тем самым формируя виртуальную память больше чем физическую, поэтому свернув окно до 160x100 пикселей (была такая опция, не помню хоткей) можно было вполне запустить и на 2 МБ в DOS-сессии командной строки.
А что если будет некий платный сервис для разработчиков, который будет содержать хранилище персональных данных оформленное полностью в соответствии с РКН и предоставлять хеши пользователя (может даже одноразовые для сессии, истребуемые движком целевого сайта). И те, кто не хочет лишний раз связываться с этими процедурами могут просто запросить в форме "введите ваш
ORCIDID,SPIN-код РИНЦ" для прохождения регистрации. В принципе даже пароль не нужен и какие-либо скрипты. Персональные данные вытягиваются из официальной базы данных с которой уже подписан договор о предоставлении таких услуг, а сами согласия об обработки пользователь уже подписывает хоть по ЭЦП с этой третьей организацией.Microsoft хороши тем, что они очень хорошо дружат с производителями железа. Скорее всего и так понятно что домашний комп или рабочая станция это фактически уже тонкий клиент и без инета скорее можно использовать как большую ардуину. Рабочие станции энтерпрайз это другая история для CAD/CAM/дизайна и там уже винда идёт корпоративная. Вообщем вполне разумное с точки зрения бизнеса решение и скорее всего путём взаимодействия с теми кто делает процы и чипсеты могут закрыть лазейки и для опенсоурса, когда будет исполняться подписанный код или даже эффективно исполняться то, что под винду, и тормозить под другие ОС, так как не будут использоваться каких-либо специализированные фишки, свойственные только майкам для внешних контроллеров (GPU, звук, диски, порты), таких узких мест на самом деле очень много.
Важен вопрос самого обучения, который представляется как некая задача оптимизации по заданному критерию. Так вот в течении жизни происходит нахождение как критериев так и поиск оптимума и чем дальше тем больше всё скатывается до некоего глобального минимума, который устраивает и отвечает требованиям характера, привычек, поведения, взаимодействия. Методы самой оптимизации можно поменять легко, это опыт, а вот критерий - это сугубо индивидуальное. Для кого-то уникальные 10 строк кода - это супер, для другого - 10 пойманных многоклеточных на обед - достижение, и то и другое, грубо говоря, стратегия поиска комфортных условий обитания (в противовес "дарвинизму" о борьбе за выживание)
имеется в виду разумных инопланетян. Вот представьте, приходит к Вам на работу некто, который имеет дискету с решением всех Ваших задач на 10 лет вперёд, векторные схемы, эскизы, формулы, отчёты, к кому позвонить, у кого заказать. Уверяю, 1,44 МБ сжатых данных для ключевых аспектов деятельности за это время более чем достаточно (в этом плане некто прав, что и 640 кБ хватит всем). По всем критериям этот некто - инопланетное существо. А по факту вскоре это будет ИИ.
1/10 c это уже скорости, на которых уже возможен полноценный термоядерный синтез, например для микстуры дейтерий-тритий оптимум, соответствующий паре десятков килоэлектронвольт это 1% от скорости света. То есть любая прилетевшая "молекула" в космический аппарат уже может не то что выбивать из оболочки всё что можно но и вступать со всем этим делом в ядерные реакции. Единственный возможный вариант - вызвать локальное прерывание в компьютере, моделирующим нашу Вселенную. Вообщем программная точка останова наподобие ловушки IRQ 3, осталось её только найти методом подбора, далее подменить стек пространства-времени и сделать return уже в другой точке адреса возврата.
Гораздо более захватывающая история - это диффузия за миллиарды лет углекислоты, воды и прочих активных веществ в металлы. Этакая космическая ржавчина. Хотя если посчитать среднюю плотность водородной плазмы как десяток атомов на кубометр (даже если это нейтральные молекулы, на скоростях десяток км/с имеют эффективную температуру в тысячи град, очень грубо - формула тепловой скорости √3kT/m), то за миллиард лет с этим водородом прореагирует лишь 1 см поверхности кометы. Однако, при прохождении плотных облаков, остатков сверхновых там может быть другая ситуация. Поэтому такие путешествия вбирают в себя историю как годовые кольца на деревьях, выглядит это как плазмохимическая обработка но практически без объёмного нагрева поверхности, которая нагрета чуть больше чем реликтовое излучение. Но если она проходит рядом со звездой запускаются совсем иные механизмы, связанные с теплом. И вот эта вся накопленная за эти "годы" (невероятно представить, что это от начала Архея до человека) химия начинает сублимировать
Точно! Поторопился с квадратом, это для массы. Действительно
и ![r \propto \sqrt[3] {m}](https://habrastorage.org/getpro/habr/upload_files/0b2/bd1/7d1/0b2bd17d12acf1f264b26c885dcc5008.svg)
, следовательно относительный радиус растёт как 
, как раз 
. Примерно тоже самое относится и к ядерным взрывам, диаметр fireball от мегатонн и давнишние споры о величине Тунгусского метеорита, хотя если он состоял из воды, она вполне могла на таких скоростях сначала превратиться в плазму, диссоциировать на микс водород-кислород а потом опять "сгореть" до воды.
Обычная скорость объектов из пояса астероидов до 20 км/с при столкновении, из облака Оорта под 50, здесь же при ускорении Солнцем может быть и все 100. Так что 5 км согласно
легко превращаются в 25. Так что достаточно небольшой межзвёздный метеорит может вызвать последствия, завершившие эволюцию не птичьих динозавров.
Совершенно верно. В этой концепции в принципе нет разделения на тип хранилища объектов. Это может быть облако сервер:порт, сайт https, запрос к БД, к диску C: или по UART к контроллеру. Система управления версий изначально была заточена под управление именно файлами а не непосредственно программными элементами. В этом и есть главная беда. Потенциально в новых подходах указывается источник данных и необходимые атрибуты, такие как версия, хеш, дата, некое имя/ID (например, обозначающее ветку), и указывается для конкретно того что нужно - пространства имён, функции или класса. Нет смысла тянуть файл который на усмотрение разработчиков может содержать пиктограммку в Base64 просто потому что так захотелось. Также на уровне линковки в elf/so/dll уже давным давно должны появиться атрибуты версий объектов, идентификаторы, контрольные суммы. Поэтому посреди бинарников всегда можно выбрать только то что необходимо а не дублировать всё по папкам или релизить вместе с программой, также это позволяет инкапсулировать то что является условно read-only как системная библиотека, что-то в локалях у пользователя что-то вместе с программой. Указывая эти идентификаторы практически полностью можно исключить ошибки линковки при встрече двух файлов, т к. линкёр уже будет знать что именно из них вытягивать, в противном случае надо играться с path который будет показывать откуда что брать, это вечная проблема когда необходимо держать локальный зоопарк из нескольких версий. Более того, если в объектнике, формат которого не менялся с середины 80-х будут уже более современные атрибуты, связанные с управлением версиями а не просто 64 бит этикетка, их можно объединять и укрупнять а имя файла или либы уже значения иметь не будет, содержимое может быть индексировано уже на уровне ОС, плюс взаимосвязь с объектами включения, чтобы заголовочники были также синхронизированы с dll/so (это отдельная боль), в этом случае добавляется инструкция с идентификатором, позволяющая точно согласовать версию заголовочника и двоичника.
Так все новые фичи для компилятора могут быть инициированы как внутри исходника, например, какой-либо прагмой зависящей от версии а также явным указанием. Например gcc поддерживает опции -std=c23 или что-то вроде -std=iso9899:2023. При компиляции можно указать какой именно стандарт и расширение использовать. Вообщем в любом случае все эти свистки командной строки должны уйти внутрь кода и самого языка и убрать файл как структурную единицу проекта, это ведь просто именованная запись а не сам код так сказать. Иными словами проблему путей, линковок, зависимостей, символических ссылок, всяких copy/rm/ls и прочих песен с файлопапками искоренить на уровне идентификаторов и пространств имён в самом языке. Компилятор будет понимать файлы и подкаталоги как единое целое, но внутри вполне всё может быть разбито на проекты, например, ключевым словом project, нечто вроде архива, производить индексацию библиотек, синхронизацию итд. Вообщем это уже комбайн для сборки, но один, без распыления на отдельные утилиты со своими капризами и запросами. То есть меняется мировоззрение по самому представлению проекта уже вне файловой системы на языке предметной области. Конечно все привыкли к тому чему учили, но это не может уже продолжаться полвека.
Механизм Enter-Exit создаёт блокировку "прерываний" внутри процесса, это выглядит как некий аналог GIL или Enable/Disable interrupt в контроллере или Enter/LeaveCriticalSection, поэтому, должна быть гарантия что внутри этого процесса код будет выполнен за фиксированное время и не возникнет таймаутов. Чистое многопроцессорное (не просто многопоточное) исполнение позволяет делать некий эквивалент вложенных прерываний. Поэтому конечно хотелось бы чтобы общение с процессом шло через FIFO или SharedMemory (с управлением оной), это позволит избежать дублирования внешних стеков данных, которые должны как-то ещё обрабатывать критические секции (привет всевозможным флажкам состояний) особенно если там динамическая аллокация памяти без специальных Interprocess-средств и управление кучей.
Интересно, в принципе в зависимостях более чем достаточно для GUI всяческих libGL*, но зачем там столько дополнительных libX11 (GLX), а как же Wayland, который EGL? Хотя вроде как Mesa тоже имеется.
Вот, потихоньку всё начинает приходить к общему знаменателю, который ещё вывел Ван Россум для Python-а в далёком 91м году на основе ОС Амёба. Там в конце довольно интересная публикация от 88 года на предмет Parallel make. Так вот тогда ещё предполагалось что среда разработки и язык могут стать единым целым и помогать друг другу. Это к вопросу к табуляциям которые фактически и являются атрибутами вложенности и области видимости. Также можно было бы точно такие же фичи сделать для комментариев и иных вещей. Вообщем спустя 40 лет похоже будет очередной виток.
Feb1991: X\Python\ does not (yet!) provide an intelligent input line editing Xfacility, so you have to type a tab or space(s) for each indented line. XIn practice you will prepare more complicated input for \Python\ with a
Это уже другой вопрос что сложность понимания кода дополняется сложностью понимания вспомогательных инструментов - помимо языка надо знать bash/bat/git/флажки компилятора, различные прагмы-макросы, непосредственно make-языки. Иными словами количество вбираемой информации не изменится если её часть переместится внутрь языка и станет его атрибутом, то есть можно использовать можно нет. Ну это как С++ вместо ООП и прочего синтаксического сахара можно вполне использовать как С с классами или просто как процедурный. Бывало даже видел программы состоящие прямиком из asm-вставок, компилятор нужен был только для аргументов функции и возврата. Поэтому код, который удобно отлаживать, делать опции при сборке для тех или иных компонент кода, а не файлов, будет гораздо лучше чем если это дело отдельно отдать управлять внешним инструментом который просто сложился исторически а не был создан изначально, плюс набегают ошибки, когда действие делается не одним инструментом а двумя и более, много синхронизируемых сущностей, там один флажок, здесь другой, там имя файла не совпадает там ещё что-то, часовой пояс поменяли до уровня up to date, переменную среды не прописали, path не туда. То есть за кодом тянется дополнительная вереница исключительно системных дел. Если это уйдёт в код то он станет самособираемым и практически исчезнет необходимость во внешнем инструменте. Там на самом деле не так много необходимо будет выучить. Думаю ключевых слов version, debug, link, map, control, request, exclude, update, hash, options, optimize, code_id, testfunc и что то в этом роде будет не так много, которые практически полностью позволят настроить как и что собирать если что-то не нравится по умолчанию. Движение на этот счёт имеется в виде танцев с бубном но как-то слабо из за гигантского легаси и разросшихся вспомогательных инструментов, что пора бы уже комитету C++26 уже сделать более дружелюбным к системам сборки и версионирования наравне с другими языками.
Именно так. Что изменение коммента не есть изменение кода что не нужно перекомпилировать весь мир или обходить это с использованием иных абстракций. То есть в самом коде начинают присутствовать элементы версий, git, контрольные суммы, даты/дескрипторы создания, модификаций функций и классов, включая всевозможные фичи для отладки вроде лишних assertion, опций оптимизации конкретного фрагмента кода начиная от -O0 и заканчивая -O3, когда необходимо отладить только вот какой-то конкретный кусочек функции без её вытаскивания в отдельный файл, прагмы станут уже нормальными опциями для статического динамического размещения, map/ld-файл уже как-то ближе к коду а не отдельная сущность, включая настройки, нормальные унифицированные интрисики как стандартное расширение языка и многие другие фишки. Вообщем система сборки должна уже давным давно проникнуть внутрь компилятора и стать его частью а не костылём снаружи, включая управление precompiled headers, опций изменений, макрорасширений/шаблонов, внешние ссылки на линковку по идентификаторам а не по файловой мешанине, избежать дублирование зависимостей итд итп.
Для эмбеддера если нет пина для подключения осциллографа, особенно петельки для земли из печатной платы, то это уже не отладочный комплект. Если по бокам был бы угловой PLD со всей периферией, расфасованной по функциям а не по номеру GPIO, то отлично, если с другого бока JTAG - вдвойне.