mayton2019

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) - можно перейти к кватерниону и там вроде как вращение легче идет.

Он называется guard expressions., и имеет отношение к pattern matching.

Нет. То что ты нарисовал - это просто форматирование.

Тема хорошая. Только вот градус амбиций я-бы сбросил. Попробуй просто написать сокетное приложение
которое передает события из точки А в точку Б. И придумай механизм персистенции. И балансировщик. И кластер. Да. правильно написал про Raft. Не только Raft. Еще есть Paxos используется в Cassandra. И централизованный ZooKeeper.

Где почитать - я даже не знаю. Спектр технологий такой широкий. Тут и сети. И многозадачность. И хранение информации.

Кстати Кафки в дефолтной комплектации почти не бывает. Каждый кастомер конфигурирует для себя регуляторы скорость-надежность. Влево-вправо. Понимаешь? Поэтому до того как "убивать" Кафку надо просто понять что любое ее нагрузочное тестирование просто ставит другие вопросы. А что собстенно вы ходите. Доставить опционально но быстро. Или с гарантией что месседж сохранился. Или с гарантией что сохранился в основной кластер и в реплику. Каждый кастомер еще для себя придумывает partitioning strategy что является очень важным аспектом скорости Kafka. Тоесть еще до бенчмарка нужно все эти вопросы проговорить. Иначе выйдет сравнительное тестирование "бульдога" и "носорога". И любая система которая будет быстрее Кафки на самом деле будет просто системой заточенной на более узкие условия. Это как узкий UDP может быть быстрее чем TCP но ... как говорил Василий Иванович есть один "нюанс".