Второй закон термодинамики работает только в идеальной закрытой системе, которых в принципе не существует.
Зачем приводить этот устаревший пример с демоном, когда давно существует динамический хаос.
Энтропия уменьшается со временем, за счет самоорганизации. Вся биосфера уменьшает энтропию.
Стрела времени возникает не из за энтропии, а из-за необратимых хаотичечких процессов. Если перемешать краски ламинарным способом, без турбулетности, то если мешать в другую сторону, то они снова восстановятся. Это реальных эксперемент.
Организм самодостаточен и без "сознания". Все эти потоки информации и так сводятся в один в подсознании.
При раздвоение личности, лунатизме и при полной амнезии сознание функционирует. Так же разделении полушарий, разделяется сознание на два независимых. При этом каждое из них оправдывает действие другого.
Т.е. сознание - куда более сложное и комплексное свойство, чем просто надстройка.
Эволюционнаям функция сознания - в том чтобы организм действовал нетипичым образом, чтобы быстро адаптироватся к ситуации которой еще не было. Ещё получать новый опыт из воспоминаний.
Сознание - синергетичечкий эффект в следствии эволюции. Память появилась намного раньше, когда появились первые нервные клетки. Это уже биологи лет 60 сформулировали.
Вот эти все "ученные" которые пишут статьи, которые не основаны ни на чем, и не несут никакого смысла - они еще за это получают деньги?
Ну хорошо что не упоминается богомерзкое визуальное программирования. Для ui это хорошо, но для систем это совершенно не подходит и на порядок сложнее обычного кода. Это лишь иллюзия что оно проще.
Но все равно, каждое no-code решение должно быть лишь доп иструментом, которое в итоге генерит код и наоборот.
Императивные языки не очень подходят для математического языка. Самое главное - чтобы все формулы были читаемы. Наилучшая реализация у wolfram mathematica. Ну и F# более-менее удобно с лямда.
Обычно оставляем ссылку в комментариях на мат. формулу, и все переменные называем в точности как там.
Программа - это строго линейный набор инструкций для машины тьюринга. Это определения для императивных языков. Программирование в первую очередь, связана с декомпозицией до состояния этого списка команд.
Машина состояний не является тьюринг полной, поэтому не является полноценной программой.
Для функционального и асинхронного программирования, программа - это уже не набор инструкций, но все равно тьюринг полное.
Не очень удачная идея придумывать отдельный скриптовый язык, замучаетесь поддерживать и обучать дизайнеров. Если прям нужен отдельный язык - то удобнее использовать F# для его написания или писать на c# script.
Но для квестов это излищне. Мы писали обычные иенумераторы для сценариев, чтобы была асинзронщина, а логику делали командами(and, or, not) и синхронизировали это с игровыми ивентами. Затем делался удобный нодовый редактор для геймдизов, который генерил уже чистый и читаемый с#, и наоборот.
Хотя микросервисы позаимствовали с веба, как там реализуют не очень знаком.
Обычно их помещают в DI-контейнеры, который уже внедряет фабрика. Иницилизируются они в строгом порядке сразу все, так как зависимости между ними в любом случае будут.
Контейнеры еще позволяют очень удобно тестировать и удалить все #ifdef в коде, которых и не должно быть в принципе.
Но непонятно как их масштабировать дальше, когда их уже сотни.
Если сервисов меньше 10 то можно сидеть на синглтонах. Если их меньше 50, то нужен gi-контенер для сервисов. Если их еще больше, то уже нужно разбивать на слои Model, View, VM.
Основная проблема микросервисов, в том что они противоречат SOLID, поэтому микросервисы обязаны быть независимы друг от друга, без иерархии, вечноживущие и всегда доступны. Ну и не допускать "ад синглтонов" и никаких "хелперов"
В спагетти-коде сроки всегда непредсказуемы и занимают много времени. Это главный фактор.
Разработка всегда подрузумевает итеративность. Решение нужно не одно, а как минимум три(с минимальным изменением кода, костыльное, хак, решение за раз сразу несколько задач, переделка, идеалистическое) и выбирается оптимальное. Костыльные решения - самые долгие в итоге, это кредит времени от будущего.
Для точной оценки применяется декопозиция задачи, варианты решения и по каждой из них строится оптимистическое время, ожидаемое, пессемистическое. Сроки от балды и сроки манагеров вообще не отражают реальность.
Манагер дает максимальные сроки согласно установленному плану, так как от этого зависят все остальные задачи.
Вы путаете язык и платформу. Тот же С++ может быть скомпилирован и на .Core, x86, Arduino, GPU. Общее между ними только синтаксис.
C# и F# на одной платформе .Core и CLR , это значит что можно на обоих языках писать в фукнциональном и императивном стиле, или писать сразу на двух языках одновременно.
Тот же C# может быть и для платформы Mono, WebAssebly и Unity3d.
Второй закон термодинамики работает только в идеальной закрытой системе, которых в принципе не существует.
Зачем приводить этот устаревший пример с демоном, когда давно существует динамический хаос.
Энтропия уменьшается со временем, за счет самоорганизации. Вся биосфера уменьшает энтропию.
Стрела времени возникает не из за энтропии, а из-за необратимых хаотичечких процессов. Если перемешать краски ламинарным способом, без турбулетности, то если мешать в другую сторону, то они снова восстановятся. Это реальных эксперемент.
Организм самодостаточен и без "сознания". Все эти потоки информации и так сводятся в один в подсознании.
При раздвоение личности, лунатизме и при полной амнезии сознание функционирует. Так же разделении полушарий, разделяется сознание на два независимых. При этом каждое из них оправдывает действие другого.
Т.е. сознание - куда более сложное и комплексное свойство, чем просто надстройка.
Эволюционнаям функция сознания - в том чтобы организм действовал нетипичым образом, чтобы быстро адаптироватся к ситуации которой еще не было. Ещё получать новый опыт из воспоминаний.
Сознание - синергетичечкий эффект в следствии эволюции. Память появилась намного раньше, когда появились первые нервные клетки. Это уже биологи лет 60 сформулировали.
Вот эти все "ученные" которые пишут статьи, которые не основаны ни на чем, и не несут никакого смысла - они еще за это получают деньги?
Ну хорошо что не упоминается богомерзкое визуальное программирования. Для ui это хорошо, но для систем это совершенно не подходит и на порядок сложнее обычного кода. Это лишь иллюзия что оно проще.
Но все равно, каждое no-code решение должно быть лишь доп иструментом, которое в итоге генерит код и наоборот.
Отбор по новизне, кстати, намного эффективнее, чем естественный. Ну кроме быстросходимых задач.
А какие различия между готовыми контроллерами и передатчиками для fpv, и arduiono? Что дешевле и проще?
В принципе без разнице на каком языке будут комманды, программировал на 1с. Но даже там перешел на латиницу.
Придется постоянно переключать раскладку, чтобы ввести специальные символы.
У некоторых ide до сих пор проблемы с кодировкой и поиском.
В английском существенно короче слова. Правописание и времена противопоказаны в программирование, а краткость, читаемость и емкость - самое важное.
А есть программирование с китайским синтаксисом? Интересно как оно выглядит.
В данных примерах напрашивается внедрение зависимостей и ioc-контейнер. А как именно фабрика будет собирать обьекты нет так важно.
А множество аргументов и наследование -зло
Императивные языки не очень подходят для математического языка. Самое главное - чтобы все формулы были читаемы. Наилучшая реализация у wolfram mathematica. Ну и F# более-менее удобно с лямда.
Обычно оставляем ссылку в комментариях на мат. формулу, и все переменные называем в точности как там.
А код-ревью кто делает? Только один архитектор на всех?
Как архитектор обучает других чистому коду и мониторит костыли?
Программа - это строго линейный набор инструкций для машины тьюринга. Это определения для императивных языков. Программирование в первую очередь, связана с декомпозицией до состояния этого списка команд.
Машина состояний не является тьюринг полной, поэтому не является полноценной программой.
Для функционального и асинхронного программирования, программа - это уже не набор инструкций, но все равно тьюринг полное.
А в чем смысл был делать 2д и тем более изометрию, при условии что все это конвертируется из 3d? Это дольше, намного сложнее и будет тормозить.
Лучше сразу делать 2.5d или 3d.
Код не могу дать, NDA . Прототип ранний могу:
https://github.com/svLimones/SOLIDex/blob/master/ScenarioService.cs - сервис
https://github.com/svLimones/SOLIDex/blob/master/OrScenarioStep.cs - команда логики
https://github.com/svLimones/SOLIDex/blob/master/LibraryOpenDialogScenario.cs - пример сценария
Для этого нужна SOLID-архитектура и что-то похожее на RX-ивенты.
Нодовый редактор можно найти готовый, тулза больше всего по времени требует, но ничего сложного и можно ее сделать потом.
Не очень удачная идея придумывать отдельный скриптовый язык, замучаетесь поддерживать и обучать дизайнеров. Если прям нужен отдельный язык - то удобнее использовать F# для его написания или писать на c# script.
Но для квестов это излищне. Мы писали обычные иенумераторы для сценариев, чтобы была асинзронщина, а логику делали командами(and, or, not) и синхронизировали это с игровыми ивентами. Затем делался удобный нодовый редактор для геймдизов, который генерил уже чистый и читаемый с#, и наоборот.
Упс, перепутал микросервисы с обычными сервисами.
Хотя микросервисы позаимствовали с веба, как там реализуют не очень знаком.
Обычно их помещают в DI-контейнеры, который уже внедряет фабрика. Иницилизируются они в строгом порядке сразу все, так как зависимости между ними в любом случае будут.
Контейнеры еще позволяют очень удобно тестировать и удалить все #ifdef в коде, которых и не должно быть в принципе.
Но непонятно как их масштабировать дальше, когда их уже сотни.
Если сервисов меньше 10 то можно сидеть на синглтонах. Если их меньше 50, то нужен gi-контенер для сервисов. Если их еще больше, то уже нужно разбивать на слои Model, View, VM.
Основная проблема микросервисов, в том что они противоречат SOLID, поэтому микросервисы обязаны быть независимы друг от друга, без иерархии, вечноживущие и всегда доступны. Ну и не допускать "ад синглтонов" и никаких "хелперов"
В спагетти-коде сроки всегда непредсказуемы и занимают много времени. Это главный фактор.
Разработка всегда подрузумевает итеративность. Решение нужно не одно, а как минимум три(с минимальным изменением кода, костыльное, хак, решение за раз сразу несколько задач, переделка, идеалистическое) и выбирается оптимальное. Костыльные решения - самые долгие в итоге, это кредит времени от будущего.
Для точной оценки применяется декопозиция задачи, варианты решения и по каждой из них строится оптимистическое время, ожидаемое, пессемистическое. Сроки от балды и сроки манагеров вообще не отражают реальность.
Манагер дает максимальные сроки согласно установленному плану, так как от этого зависят все остальные задачи.
Вы путаете язык и платформу. Тот же С++ может быть скомпилирован и на .Core, x86, Arduino, GPU. Общее между ними только синтаксис.
C# и F# на одной платформе .Core и CLR , это значит что можно на обоих языках писать в фукнциональном и императивном стиле, или писать сразу на двух языках одновременно.
Тот же C# может быть и для платформы Mono, WebAssebly и Unity3d.
F#, Haskel, BrainFuck уже и так знаю. XAML и SQL - это вообще не языки программирования.
Если вы не можете загуглить несколько основных команд и синтаксис языка - то вы некомпетентны. Это умещается в одну страницу.
А вот на изучение платформ .Core, Java VM, x86 и других, может уйти десятилетия, и в основном методом проб и ошибок.