MWI не решает проблему наблюдателя, и с этой точки зрения ни чем не лучше остальных интерпретаций. Кроме того, она приводит к таким интересным эффектам как "квантовое бессмертие", которые полностью выпадают из научного контекста ввиду отсутствия объективности (субъективный идеализм).
Существование этих ветвей неизбежно следует из формул квантовой механики, как структура пространства внутри черной дыры следует из формул Эйнштейна.
Из квантовой механики следует только то, что живомертвого квантового кота наблюдает радостногрустный квантовый наблюдатель. Все остальное — попытки разрубить радостногрустного квантового наблюдателя на двух классических. Только коллапс рубит лишь наблюдателя, а MWI заодно еще и всю Вселенную вместе с ним.
С одной стороны, возможны самосогласованные и непротиворечивые описания, требующие бесконечного числа постулатов, которые нельзя свести к конечному числу никаким образом (следует из теоремы Гёделя о неполноте). С другой стороны, автор утверждает, что любая математическая система описывает какую-либо "реально" существующую Вселенную или класс Вселенных (как ваша "жизнь" с фишками например). Тогда должны существовать Вселенные, для описания которых требуется бесконечное число утверждений.
И не факт, что наша не такая. Просто мы энергетически ограничены в области, где более-менее действует одна и та же физика.
Когда ученые говорят о Теории Всего, они неявно предполагают три совершенно неочевидных и спорных допущения.
Вселенная может быть описана на каком-то фундаментальном языке. Ни одна описательная система не может быть применена сама к себе. Ни откуда не следует, что выстроенный нами математический фундамент формально верен. На сегодняшний день есть определенные успехи в математическом методе, но вряд ли это будет корректно экстраполировать сразу на все. Как контр пример можно представить Вселенную с Богом — и наша математика сразу перестанет работать.
Такое описание будет единственным. Например на сегодняшний день есть несколько струнных теорий, описывающих одну и ту же физику частиц, но данные теории не эквивалентны и не совместимы между собой. Может случится так, что будет существовать не одна Теория Всего, а бесконечное множество, описывающих одну и ту же Вселенную в совершенно разных понятиях и методах.
(самое на мой взгляд критичное) Такое описание будет конечным. Здесь можно сослаться на теорему Геделя о неполноте. Вполне возможно, что изучая Вселенную глубже и дальше, каждый раз будут находиться новые детали, так или иначе не вписывающиеся в существующую систему, и которые потребуют введения новых постулатов и моделей. И так до бесконечности. Хотя в нашем случае мы очень быстро подойдем к техническому пределу познания, дальше которого заглянуть не удастся.
Ну и естественно, отдельным вопросом будет стоят полезность данной теории. Описание будет настолько абстрактным, что может быть применимо сразу ко всему и объяснять сразу все, но ничего конкретного давать не будет. И такое описание существует уже давно практически во всех религиях...
Spring Boot — это самая настоящая катапульта. Она позволяет быстро написать приложение "Хелло ворлд" с кучей подключенных технологий, абсолютно не задумываясь о том, как это все работает. Реализация какой-то специфической задачи, не входящей в стандартный стек решений, уже не так тривиальна: требуется вдумчиво читать документацию, зазубривать конвеншны и @Заклинания, смотреть в кинотеатре сагу от Евгения Борисова и сильно уметь копаться в коде спринга. И все это в том случае, если программа более-менее написана грамотно.
А экономим мы усилия по написанию всякого сервисного кода и сдруживанию разных зависимостей, которые не всегда можно быстро сдружить.
Зачастую это кажущаяся экономия. Катапульты пытаются охватить сразу весь типовой стек решений (config + IoC + rest + database + integration + etc...). Однако интегрировать новую зависимость во фреймворк бывает на порядок сложнее, нежели в кастомном коде. А зачастую головную боль создают ограничения фреймворка, которые приходится грязно обходить. В особенности, когда не знаешь как оно внутри там вертится...
Что меня больше всего настораживает во всех этих катапульт-фреймфорках — это то, что потом любое изменение "не по плану" всегда оборачивается жуткой головной болью. И в что мы экономим? Лишних полчаса, чтобы собрать проект из явных зависимостей?
jBoss как раз для разработки «так себе», память при интенсивном деплое/редеплое утекает влет.
Это общая проблема всех серверов, когда единственный несобранный указатель на класс приложения "держит" весь класслодер и контекст приложения, причем ошибка может быть как в конфигурации, так и в самом приложении. Частая ошибки — использование ThreadLocal в серверном пуле, либо "кеширование" бинов и системных ресурсов в static-полях. Поэтому на проде рекомендуют при undeploy-е рестартовать сервер.
Я имел ввиду другое — у JBoss хорошее окружение: cli, vfs, документация, конфигурирование, хорошо организована структура папок.
Помниться неделю убил на установке WebSphere 7 на локальную машину под Linux.
Абсолютно та же фигня, причем на протяжении разных версий и разных продуктов. WAS 8.5 не ставился из официальных дистрибутивов без извращений, в патчинге полный разброд — для одних фиксов нужен был Installation Manager (причем одновременно разных версий), другие ставились "на сырую" без возможности "отката", документация только на установку занимает 240 страниц. Такое впечатление, что IBM делает свои продукты не для людей. Хотя, надо отметить, будучи заведенными, работают достаточно стабильно.
Вот кстати с Websphere (который коммерческий, не Liberty) и в особенности с тем, что шло поверх с маркой "Business" сильно не срослось. Один из худших серверов, который я видел. Weblogic лучше, где особенно радует админка и единый тунелирующий протокол t3 на основе http. JBoss однозначно самый developer-firendly, отлично работет саппорт, плюс хороший стек решений на базе. Для локального девелопмента и тестов есть хороший проект http://openejb.apache.org/ фактически единственный, который позволяет пускать embedded-контейнер и полностью его конфигурировать программно.
А кому сегодня впились эти спецификации? Они неюзабельны (для примера возьмите хотя бы веб-профайл), неполны, выходят с огромным запозданием, плохо кастомизируемые, и зачастую не покрывают даже самые базовые потребности девелопмента, такие как тестинг и конфигурирование.
А что такое сервер приложений? Я поражаюсь как более десяти лет компании умудрялись продавать класслоадер со стандартным набором open-source библиотек и админкой. Выросло целое поколение людей, которые не знали, что в java есть public static void main() и что приложение может работать без томкэта.
Путь создания имплементаций поддерживающих «profiles» (например «web profile») верный — понимаешь чего ждать, а чего не ждать от платформы.
Нынче "профайл" делается при помощи депенденси в мейвене или грэдле, и такой, какой душе угодно.
Телеграм тоже не радиоактивен, но его-таки запретили.
Смотрим статью 220 уголовного кодекса: Незаконные приобретение, хранение, использование, передача или разрушение ядерных материалов или радиоактивных веществ...
Т.е. т.н. "ядерный материал" вовсе не обязан быть радиоактивным. По запросу "ядерный материал" выходит постановление "об учете и контроле ядерных материалов", который устанавливает перечень ядерных и специальных неядерных материалов, подлежащих государственному контролю. К последним относится наш дейтерий.
То есть производство, хранение и сбыт дейтерия контролируется государством. Так что как минимум "без вопросов" не получится. А вот уже потом "кококо и кудах кудах".
Народ, а откуда дровишки дейтерий? Я так понимаю, в аптеке он не продается, самопальный сепаратор сделать будет раз в десять сложнее всей установки. Кроме того, как там с законом и порядком? В России за оборот ядерных веществ сразу дадут двушечку.
Вот совсем не так устроен, даже не близко.
Для начала сделайте обработку запроса в отдельном треде: либо новом, либо из пула. Это добавит всего пару строк, но сделает ваш сервер многопользовательским. А то вы так бодро и оптимистично из сокета читаете, что как-будто кто-то обязан доставить вам незамедлительно весь http-запрос, а также моментально отправить ваш ответ. А вот треды исключат блокировку, и ваш сервер сразу станет актуальным на период до 2002 года.
В 2002 году вышла Java 1.4, в которой, наконец, запилили неблокирующий NIO, который предлагал совершенно другую модель взаимодействия. Треды стали ненужны, ну или не столь актуальны, но прогать стало на порядки сложнее. Поэтому Apache Mina или Netty.
точно знать где и что лежит, а не шариться по диску, ища кто, что и где сохраняет
указать где их надо создавать, хотя бы при первом запуске программы
держать независимо от основной программы
делать бекапы и прочее
Все остальное, включая конфиги программы, кеши и индексы — это мусор, который всегда можно преспокойно снести, либо для особо одаренных предложить опцию.
Что мы имеем, благодаря данному "стандарту" — это очередной набор помоек, куда каждый будет сваливать что хочет. В моем .local/share сейчас 63 директории, включая data/LibreCad, ibus-table, xorg, gegl-0.2, gegl-0.3, и прочая херь, которая бесполезна и остается после сноса программы, и рядом с которой я не хочу держать действительно важные для меня данные.
Ваша спецификация — гвн (с) самизнаетекто.
От того, что все дерьмо из $HOME/.* раcкидают по другим директориям, оно не перестает быть дерьмом. Особенно примечательно, когда пакет/программа удаляется, а ее отложенные личинки еще по всему дереву собирать приходится. К тому же давно пора проапдейтить package manager, чтобы при удалении подчищал за собой.
Для того чтобы многозадачность работала нужна конкуренция.
Вовсе не обязательно. Конкуренция (и все, что было описано выше) нужна там, где появляется shared state и race conditions. Именно для доступа к общей памяти и служат все эти JMM, локи и другие примитивы, а не для управления многозадачностью как таковой. В Unix вы управляете многозадачностью из шелла и строите потоковую обработку данных при помощи pipes, при этом у вас работает параллельно сразу несколько процессов, но отсутствует shared state и конкуренция (по крайней мере въявную).
Почему так популярна модель с потоками?
Потому-что Unix. POSIX-потоки — это эволюция юникс-процессов. На самом деле поток — это отличное средство для изоляции выполнения задачи (еще ничего лучше не придумано): он жестко связан со стеком вызовов (алло, корутины!) и содержит в себе весь контекст выполнения ввиде локальных переменных (привет, коллбеки!). Основным недостатком является жесткая привязанность к ресурсам системы и невозможность сериализации/персистенции, например в случае длительной блокирующей операции. Хотя на этот счет есть свои решения.
На самом деле самая главная проблема в том, что кто-то решил, что выполнять что-то на машине клиента — это достаточно безопасно, если это "что-то" немного в чем-то ограничить.
Все-равно необходим какой-то кодогенератор, иначе много бойлерплейта получается, особенно когда у вас сильно больше двух полей. Еще такая сильно неудобная вещь, как мутирование полей у nested-объектов:
user = user.setContact(user.getContact().setAddress(user.getContact().getAddress().setStreet("Lenina"));
когда хотелось бы что-то вроде:
user = set(User.contact.address.street, "Lenina");
По-идее так и нужно делать, но уж больно смахивает на обычный конструктор. Когда полей немного проще всех запихать в конструктор (или несколько перегруженных), объявив опциональные значения как @Nullable, и вообще не заморачиваться ни с какими билдерами. Я вообще все поля делаю public final, чтобы еще и геттеры убрать. Вот в Immutables у билдеров есть очень полезная фича — это клонирование объекта с изменениями.
Просто чтобы понять суть многих проблем, посмотрите обсуждения, которые велись в блоге Kotlin, когда он еще был на этапе дизайна. Там тоже предлагали многообещающие нововведения, от большинства которых впоследствии пришлось отказаться, например от функции с множественным результатом. Некоторые из них все же были реализованы, но совсем в другом виде.
С присваиванием все просто — доступ к полю приоритетнее, и тогда ничего из уже написанного не сломается. И даже хрен с ним уж с присваиванием — пусть так и оставят setXXX(). Главная задача пропертей — это добавить сахорочку и уменьшить бойлерплейт на этапе определения объекта. Потому как более чем в 99% случаем все ваши геттеры-сеттеры — это тупо автогенерация доступа к полю. Для всех остальных случаев оставить обычный фолбэк в геттеры-сеттеры.
Сейчас для создания одного! свойства в Java приходится писать его имя 7-12 раз, его тип 3 раза, 2-3 раза повторяющийся джавадок и в общей сложности используя 19+ слов. Это есть настоящий идиотизм.
Кроме того, я устал от классов и хочу, чтобы все было интерфейсом, и чтобы проперти можно было описывать и там.
MWI не решает проблему наблюдателя, и с этой точки зрения ни чем не лучше остальных интерпретаций. Кроме того, она приводит к таким интересным эффектам как "квантовое бессмертие", которые полностью выпадают из научного контекста ввиду отсутствия объективности (субъективный идеализм).
Из квантовой механики следует только то, что живомертвого квантового кота наблюдает радостногрустный квантовый наблюдатель. Все остальное — попытки разрубить радостногрустного квантового наблюдателя на двух классических. Только коллапс рубит лишь наблюдателя, а MWI заодно еще и всю Вселенную вместе с ним.
С одной стороны, возможны самосогласованные и непротиворечивые описания, требующие бесконечного числа постулатов, которые нельзя свести к конечному числу никаким образом (следует из теоремы Гёделя о неполноте). С другой стороны, автор утверждает, что любая математическая система описывает какую-либо "реально" существующую Вселенную или класс Вселенных (как ваша "жизнь" с фишками например). Тогда должны существовать Вселенные, для описания которых требуется бесконечное число утверждений.
И не факт, что наша не такая. Просто мы энергетически ограничены в области, где более-менее действует одна и та же физика.
Когда ученые говорят о Теории Всего, они неявно предполагают три совершенно неочевидных и спорных допущения.
Ну и естественно, отдельным вопросом будет стоят полезность данной теории. Описание будет настолько абстрактным, что может быть применимо сразу ко всему и объяснять сразу все, но ничего конкретного давать не будет. И такое описание существует уже давно практически во всех религиях...
Spring Boot — это самая настоящая катапульта. Она позволяет быстро написать приложение "Хелло ворлд" с кучей подключенных технологий, абсолютно не задумываясь о том, как это все работает. Реализация какой-то специфической задачи, не входящей в стандартный стек решений, уже не так тривиальна: требуется вдумчиво читать документацию, зазубривать конвеншны и @Заклинания, смотреть в кинотеатре сагу от Евгения Борисова и сильно уметь копаться в коде спринга. И все это в том случае, если программа более-менее написана грамотно.
Зачастую это кажущаяся экономия. Катапульты пытаются охватить сразу весь типовой стек решений (config + IoC + rest + database + integration + etc...). Однако интегрировать новую зависимость во фреймворк бывает на порядок сложнее, нежели в кастомном коде. А зачастую головную боль создают ограничения фреймворка, которые приходится грязно обходить. В особенности, когда не знаешь как оно внутри там вертится...
Что меня больше всего настораживает во всех этих катапульт-фреймфорках — это то, что потом любое изменение "не по плану" всегда оборачивается жуткой головной болью. И в что мы экономим? Лишних полчаса, чтобы собрать проект из явных зависимостей?
Это общая проблема всех серверов, когда единственный несобранный указатель на класс приложения "держит" весь класслодер и контекст приложения, причем ошибка может быть как в конфигурации, так и в самом приложении. Частая ошибки — использование ThreadLocal в серверном пуле, либо "кеширование" бинов и системных ресурсов в static-полях. Поэтому на проде рекомендуют при undeploy-е рестартовать сервер.
Я имел ввиду другое — у JBoss хорошее окружение: cli, vfs, документация, конфигурирование, хорошо организована структура папок.
Абсолютно та же фигня, причем на протяжении разных версий и разных продуктов. WAS 8.5 не ставился из официальных дистрибутивов без извращений, в патчинге полный разброд — для одних фиксов нужен был Installation Manager (причем одновременно разных версий), другие ставились "на сырую" без возможности "отката", документация только на установку занимает 240 страниц. Такое впечатление, что IBM делает свои продукты не для людей. Хотя, надо отметить, будучи заведенными, работают достаточно стабильно.
Вот кстати с Websphere (который коммерческий, не Liberty) и в особенности с тем, что шло поверх с маркой "Business" сильно не срослось. Один из худших серверов, который я видел. Weblogic лучше, где особенно радует админка и единый тунелирующий протокол t3 на основе http. JBoss однозначно самый developer-firendly, отлично работет саппорт, плюс хороший стек решений на базе. Для локального девелопмента и тестов есть хороший проект http://openejb.apache.org/ фактически единственный, который позволяет пускать embedded-контейнер и полностью его конфигурировать программно.
А кому сегодня впились эти спецификации? Они неюзабельны (для примера возьмите хотя бы веб-профайл), неполны, выходят с огромным запозданием, плохо кастомизируемые, и зачастую не покрывают даже самые базовые потребности девелопмента, такие как тестинг и конфигурирование.
А что такое сервер приложений? Я поражаюсь как более десяти лет компании умудрялись продавать класслоадер со стандартным набором open-source библиотек и админкой. Выросло целое поколение людей, которые не знали, что в java есть public static void main() и что приложение может работать без томкэта.
Нынче "профайл" делается при помощи депенденси в мейвене или грэдле, и такой, какой душе угодно.
Телеграм тоже не радиоактивен, но его-таки запретили.
Смотрим статью 220 уголовного кодекса:
Незаконные приобретение, хранение, использование, передача или разрушение ядерных материалов или радиоактивных веществ...
Т.е. т.н. "ядерный материал" вовсе не обязан быть радиоактивным. По запросу "ядерный материал" выходит постановление "об учете и контроле ядерных материалов", который устанавливает перечень ядерных и специальных неядерных материалов, подлежащих государственному контролю. К последним относится наш дейтерий.
То есть производство, хранение и сбыт дейтерия контролируется государством. Так что как минимум "без вопросов" не получится. А вот уже потом "кококо и кудах кудах".
Народ, а откуда
дровишкидейтерий? Я так понимаю, в аптеке он не продается, самопальный сепаратор сделать будет раз в десять сложнее всей установки. Кроме того, как там с законом и порядком? В России за оборот ядерных веществ сразу дадут двушечку.А в кровавом энтерпрайзе мы помним самурая Коскэ, как создателя JAXB.
Вот совсем не так устроен, даже не близко.
Для начала сделайте обработку запроса в отдельном треде: либо новом, либо из пула. Это добавит всего пару строк, но сделает ваш сервер многопользовательским. А то вы так бодро и оптимистично из сокета читаете, что как-будто кто-то обязан доставить вам незамедлительно весь http-запрос, а также моментально отправить ваш ответ. А вот треды исключат блокировку, и ваш сервер сразу станет актуальным на период до 2002 года.
В 2002 году вышла Java 1.4, в которой, наконец, запилили неблокирующий NIO, который предлагал совершенно другую модель взаимодействия. Треды стали ненужны, ну или не столь актуальны, но прогать стало на порядки сложнее. Поэтому Apache Mina или Netty.
Данные — это результат моей работы, и я хочу:
Все остальное, включая конфиги программы, кеши и индексы — это мусор, который всегда можно преспокойно снести, либо для особо одаренных предложить опцию.
Что мы имеем, благодаря данному "стандарту" — это очередной набор помоек, куда каждый будет сваливать что хочет. В моем .local/share сейчас 63 директории, включая data/LibreCad, ibus-table, xorg, gegl-0.2, gegl-0.3, и прочая херь, которая бесполезна и остается после сноса программы, и рядом с которой я не хочу держать действительно важные для меня данные.
Ваша спецификация — гвн (с) самизнаетекто.
От того, что все дерьмо из $HOME/.* раcкидают по другим директориям, оно не перестает быть дерьмом. Особенно примечательно, когда пакет/программа удаляется, а ее отложенные личинки еще по всему дереву собирать приходится. К тому же давно пора проапдейтить package manager, чтобы при удалении подчищал за собой.
Вовсе не обязательно. Конкуренция (и все, что было описано выше) нужна там, где появляется shared state и race conditions. Именно для доступа к общей памяти и служат все эти JMM, локи и другие примитивы, а не для управления многозадачностью как таковой. В Unix вы управляете многозадачностью из шелла и строите потоковую обработку данных при помощи pipes, при этом у вас работает параллельно сразу несколько процессов, но отсутствует shared state и конкуренция (по крайней мере въявную).
Потому-что Unix. POSIX-потоки — это эволюция юникс-процессов. На самом деле поток — это отличное средство для изоляции выполнения задачи (еще ничего лучше не придумано): он жестко связан со стеком вызовов (алло, корутины!) и содержит в себе весь контекст выполнения ввиде локальных переменных (привет, коллбеки!). Основным недостатком является жесткая привязанность к ресурсам системы и невозможность сериализации/персистенции, например в случае длительной блокирующей операции. Хотя на этот счет есть свои решения.
На самом деле самая главная проблема в том, что кто-то решил, что выполнять что-то на машине клиента — это достаточно безопасно, если это "что-то" немного в чем-то ограничить.
Все-равно необходим какой-то кодогенератор, иначе много бойлерплейта получается, особенно когда у вас сильно больше двух полей. Еще такая сильно неудобная вещь, как мутирование полей у nested-объектов:
когда хотелось бы что-то вроде:
По-идее так и нужно делать, но уж больно смахивает на обычный конструктор. Когда полей немного проще всех запихать в конструктор (или несколько перегруженных), объявив опциональные значения как @Nullable, и вообще не заморачиваться ни с какими билдерами. Я вообще все поля делаю public final, чтобы еще и геттеры убрать. Вот в Immutables у билдеров есть очень полезная фича — это клонирование объекта с изменениями.
Просто чтобы понять суть многих проблем, посмотрите обсуждения, которые велись в блоге Kotlin, когда он еще был на этапе дизайна. Там тоже предлагали многообещающие нововведения, от большинства которых впоследствии пришлось отказаться, например от функции с множественным результатом. Некоторые из них все же были реализованы, но совсем в другом виде.
С присваиванием все просто — доступ к полю приоритетнее, и тогда ничего из уже написанного не сломается. И даже хрен с ним уж с присваиванием — пусть так и оставят setXXX(). Главная задача пропертей — это добавить сахорочку и уменьшить бойлерплейт на этапе определения объекта. Потому как более чем в 99% случаем все ваши геттеры-сеттеры — это тупо автогенерация доступа к полю. Для всех остальных случаев оставить обычный фолбэк в геттеры-сеттеры.
Сейчас для создания одного! свойства в Java приходится писать его имя 7-12 раз, его тип 3 раза, 2-3 раза повторяющийся джавадок и в общей сложности используя 19+ слов. Это есть настоящий идиотизм.
Кроме того, я устал от классов и хочу, чтобы все было интерфейсом, и чтобы проперти можно было описывать и там.