mayton2019

Если кратко - то да. Можно.

Если более подробно - то это долго. Мучительно. И где то в конце вы создадите свой собственный
язык (DSL) который будет описывать все бизнес-преобразования данных.

Общая идея такая. Вы пишете одинаковый софт на Python для всех поставщиков данных а различия
реализуете как часть конфигураций. Пример (совершенно выдуманный):

datasources:
  - datasource: Bitcoin
    format: xls
    header: on
  - datasource: Market
    format: csv
    header: off

transformations:
  - name : Bitcoin
    filter: "WHERE payload is not null"

sink:
  - name : Bitcoin
    dest: jdbc:thin:oracle@....

Существует разумный баланс между DSL и частным решением для каждого провайдера
данных. Например с точки зрения передачи знаний для новых разработчиков решение
на DSL всегда плохое. По личному опыту коллегам всегда не нравится то, что вам кажется
красивым и концептуальным. И чаще всего DSL языки тихо умирают с уходом с проекта
главного создателя и идеолога этих всех DSL.

В качестве основы для DSL не обязательно нужен Yaml. Это можно делать на Python, Lua, Lisp
и вообще даже на основном языке. Главное чтобы конфигурационная часть была декларативной
и не содержала циклов и проверок условий.

Action Script - это как Cobol в наше время. Разработчики отрастили седые бороды и померли.

Проверь что
имя_текстполя.text
не пустое.

Проверь какое числовое значение возвращает
имя_текстполя.text.indexOf(".")

Это и будет скорее всего ответ на твой вопрос

Ассемблер полезен при анализе прошивок на безопасность.
При изучении того как работает софт без исходного кода (обратный инжинеринг)
и при решении задач интеграции разных слоёв софта.

Ассемблер также очень близко стоит к разработке компилляторов. И если у вас нет
соотвествующих знаний то строить свой компиллятор вы не сможете. Или вам нужно
будет изучать готовые back-ends, virtual-machines.

Ассемблер помогает при анализе узких мест в коде. В частности например
векторизация вычислений ставит в первую очередь вопросы на которые ассемблер
отвечает а ЯВУ - нет.

Знания ассемблера помогают сделать бинарник компактнее. Это важно при разработке
встраиваемых систем.

В целом острой необходимости нет. Особенно если ты работаешь с веб-дизайном например.
Я перешел когда мне стало интересно разворачивать Ораклы и Hadoop и прочие вещи
и мне нужна была нативная интеграция bash. Не на уровне виртуалок или докеров или WSL
а мне нужна была истинная система. Делить ресурсы 50 на 50 между гостем и хостом я не хотел.
И задачи я себе придумывал такие которые требовали hardware нагрузить на сто процентов.

Корпоративные ноуты еще долго будут под Windows11. Это стандарт де факто для офиса. И я с ним
вобщем согласен. Я-бы сказал что не звучит вопрос переходить или не переходить. А в современном
мире, в мире где допустим командная строка как способ оперативного решения задач снова возвращается
в руки разработчику (после периода забвения от Windows95) или девопсу, быть неграмотным в этой
строке просто неприлично. Нужно быть грамотным в юниксовой строке независимо от того что у вас
хост-система на декстопе.

Вообще ты сам себе ответил на вопрос

в разных отраслях для личного пользования.

Главный пользователь и заказчик - это ты. И когда ты разрабатываешь свою библиотеку векторной алгебры - то пишешь модульные тесты. И тесты, как-бы документируют твою библиотеку и закрывают все вопросы
с нулями и бесконечностями.

Какие вообще у тебя варианты по отработке неопределенностей? Я вижу такие.
1) Возвращать бесконечность +Inf. Это нормально для floating-point. Но влияние результата на стек
вызовов дальше надо учитывать. Эта бесконечность пойдет в другие формулы порождая новые бесконечности и т.п.

2) Бросать исключение. Это не в духе С++ и не всегда удобно для выскокой производительности. Но языки высокого уровня этим часто пользуются. Здесь мы предполагаем что такой результат - крайне нежелателен и работа стека расчета векторов будет аварийно прервана.

3) Возвращать специальный контейнер с результататом (Optional или Either) или пустой контейнер. Это в духе функционального кодинга. Но весь твой стек должен тоже быть адаптированным к таким Optional параметрам результатов.

И есть еще вариант - просто найти такой базис вычислений в котором нет такой проблемы. Пускай допустим векторы так и остаются основным типом данных но расчеты ты будешь делать в каком-нибудь другом типе где эта операция на уровне математики - безопасна и всегда определена. Грубо говоря как в углах Эйлера. Чтоб не писать всякие проверки условий (if) - можно перейти к кватерниону и там вроде как вращение легче идет.