Сергей

Вам просто нужно умножить вашу ЗП которую вы ожидаете на 1.5-2 ... тогда все разговоры можно продолжать и на почасовой оплате )

Ваш последний вариант по сути тот же реактивный подход. Чем он вас не устроил ?

Аппаратный рейд таит в себе неприятности. Когда рейд-контроллер выходит из строя вы начинаете с большими глазами бегать, чтобы найти такой-же. А вот если у вас софт-рейд, то вы просто поднимаете систему с теми же настройками, втыкаете диски и у вас все работает.

Пользуюсь WebYog Community Edition уже много лет, если не десятков.

1. Распознавание части тела.
2. Выявление параметров модели данной части тела (ширина, высота, углы и т.п).
3. На базе п2 вы можете построить некий скелет модели (некие характерные точки).
4. На моделях предметов должны быть обозначены данные точки.
5. Дальше дело за нехитрым: вращаем 3Д-модель согласно характерных точек п4 и определяем какие части 3Д-модели видимы, а какие загораживаются чатью тела.

У вас проблема на стороне вашего Qt кода. А именно неверная сериализация в структуры Эрланга.
Cм ссылку: erlang.org/doc/apps/erts/erl_ext_dist.html
для описания этого формата.

Вам нужно про бином Ньютона читать. Пролог тут не нужен.

Scala ?

Наймите юриста. Опишите все ему "подводные камни" которые встречали. Он вам болванку сделает. Это не дорого.

На самом деле с точки зрения правильного статистика, вам нужна не только вероятность свершения данного события. Но и доверительный интервал данного свершения.
Т.о. ваша сеть может предсказать 1% за одно действие и 99% за другое .. но если произойдет первое, это не значит что сеть "ошиблась", просто она предсказала данный исход с вероятностью не 95% .. а 1% )

> средствами PHP, значит, надо выполнить 1Сный скрипт который будет это парсить
это пипец товарищи )

А по факту распаршивания, нужно построить грамматику, сгенерировать парсер и распарсить спокойно и элементарно.

Гуглите генератор-парсеров, лексер.
YACC LEX в PHP.

Веерная рассылка по контактам из .... (заполните нужное).
Это называется именно так.

Когда вы делаете ПО вы делаете код который взаимодействует с другим кодом.
Любая функция, процедура, каждая строка --- это код который взаимодействует с другим кодом выше или ниже по тексту. Взаимодействие одного кода с другим кодом всегда осуществляется через некий интерфейс -- набор правил входа\выхода и ожиданий в поведении кода. Даже когда вы объявляете переменную в локальной области видимости - это тоже интерфейс для кода, который использует эту переменную. Другой код ожидает, что в переменная существует, имеет корректное значение, и может быть использована корректным образом. Каждый раз эти правила сосуществования кода различны, они меняются от языка к языку от разработчика к разработчику.
Лучший язык (моё имхо) - это тот язык который подходит для описания интерфейсов взаимодействия в широком смысле этого слова. Я говорю об интерфейсе как некотором контракте одного кода с другим, одной строки кода со следующей, одного оператора с другими.
Конечно существуют разные подходы для описания таких интерфейсов. Сейчас распространен принцип описательного "делай как я сказал". В этом подходе программа дробиться на простые сущности, которые каким-либо образом взаимодействуют друг с другом.
В ООП это классы-объекты, в функциональном - это функции.
Суть меняется на самом деле слабо, все это нужно чтобы:
1. формализовать описание интерфейсов взаимодействия.
2. Прийти к какому-то единообразному способу такого описания.

В ООП идут дальше, абстрагируясь от конкретной реализации класса, и вводя лишь только способы взаимодействия сущностей (описание этого взаимодействия). Т.о. появляется абстрактные классы и интерфейсы.
В функциональном способе описания также пошли в сторону абстракции. Например а Haskell есть типы и интерфейсы типов -- это что касается контрактов, и есть функции высших порядков -- это что касается реализации интерфейсов.
Такими способами уменьшается сложность ПО и дробиться код улучшается надежность.
Но даже жесткий линейный код на BASIC - это все тот же способ описать интерфейс взаимодействия одного кода с другим.

Помимо ООП и функционального программирования есть куча других методик:
Полный список можно тут взять: https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D... - и тот достаточно абстрактно-сырой.

Короче ООП это не панацея, а лишь еще один способ описания этого дивного и сложного мира и взаимоотношений в нем.

Потолки созданы чтобы их преодолевать. Сири и всякие Алисы это тупые машины которые работают по скриптам в основе которых FSM-машины (машины конечных состояний). Т.о. эти боты максимум на что способны, это только на то что заложено создателями таких скриптов. Интеллектуальности, в понимании этого слова обывателем там нет.

Есть распознавание голоса в текст, и генерация голоса по тексту. Но не больше. Дальше идет обычный код.

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