Как вам уже сказали, результат получается мягко говоря сомнительный. Но кроме того ещё и стоимость разработки получается в 4 раза больше. Так как JavaFx GUI у вас реально два человека могу пилить (плюс тестировщики периодически), а ваш WEB нужно три команды - фронт, бэк и инфраструктура. Плюс чуваки, которые этим рулят. Плюс чуваки которые это всё под конкретные платформы адаптируют. И получается, что 4х расходов на разработку, это сильно оптимистичный минимум. И это при крайне странном результате, с огромным тормозящим ненантивным приложением.
Оно ОЧЕНЬ портабельное, быстрое и правильной готовке имеет разумный размер. Плюс куча всяких библиотек. Серьёзное приложение на Compose мучительно писать. Как и на Tauri, который под капотом WEB-приложение.
Но процесс их синтеза из неорганики может быть настолько сложен, что вероятность его осуществления в количествах, достаточных для наблюдения без наличия жизни можно считать нулевой.
Вот только правильно говорить "из текущего понимания пространства-времени", так как никакого реального понимания и рядом нет.
Соответственно, пока что никто и ничто не запрещает мечтать о технологиях, позволяющих это самое пространство и/или время менять, обходя ограничение скорости света. То что такое "в природе не встречается" не означает, что это невозможно. На Земле уже и без того масса всего есть, что "в природе" встретить нельзя - только как результат деятельности жизни, иногда только разумной жизни.
Вполне себе можно допустить наличие всяких свёрнутых измерений, симметрии времени и ещё черте-чего, чего современная физика не запрещает, просто подтверждающих наблюдений нет (со временем и вовсе сплошная загадка и всё только на эмпирических наблюдениях держится).
В "большом коллективе", нужно уметь работать с этим самым коллективом и иметь стандарты разработки. Иначе важи джуны соврешненно на любом языке дичь напишут. Причём опыт показывает количество дичи не особо зависит от сложности языка, просто дичь будет в структуре кода, а не в goto, но потом найти на этапе тестирования найти эту дичь будет точно так же сложно.
Оно даже веселее. Использование иностранных мессенджеров запрещено для госучреждений. То или создать бот могла только частная контора, или это нарушение закона. В случае частной компании тоже нарушение закона, кстати, так как её никто не упономачивал. В любом случае получается нарушение закона.
Но вообще говоря, я уверен, что бота создали в ФСБ. У них уже давно есть куча наработок по мониторинговым ботам для деанонимизации пользователей путём сопоставления информации из разный телеграм-каналов. И они угрозами их активно пихали примерно везде. Примерно в половине "новостных" каналов из боты стоят. Но вторая половина оставалась неокученной. А тут такая возможность - обазять ставить бота во все каналы и давать ему админство. А я всё ждал, когда и как они своё поделие начнут заставлять в обязательном порядке ставить.
Интересно, насколько именно шифрование по ГОСТ медленнее стандартного, учитывая что обычное шифрование всем миром правят и оптимизируют, а внутри там зачастую вообще аппаратно-поддерживаемый AES, который ГОСТу Боженька запретил использовать, дав в наказание всякую содранную с DES ущербность.
Я думаю, что ГОСТ примерно на порядок более ресурсоёмким окажется. Но может и больше.
А точно плёночная клавиатура, а не механические кнопки, накрытые толстой плёнкой? Судя по виду (индикатор довольно далеко отнесёт от стекла), там вполне может плата с обычными кнопками со штырьками.
Новые версии JVM уже всё это порешали. Причём именно основываясь на опыте китайцев. Из принципиального осталось улучшить поддержку наследования примитивных типов и избавиться от boxing/unboxing. И тестовых фичах это даже уже есть и работает, но там сложные вопросы с обратной совместимостью и с языками, использующими JVM, так процесс займёт некоторое время. А остальное уже вполне себе сделано не хуже, чем у всех остальных.
У ELF-файлов есть возможность поддерживать различные таблицы экспорта для различных версий API. И потом при линковке указывать необходимую версию, которая будет выбираться рантайм при связывании загружаемых библиотек. Сильно геморно и никто этим особенно не заморачивается, но glibc заморачивается. В результате glibc вполне неплохо умеет эмулировать старые версии API самого себя - там по несколько вариантов реализации некоторых функций прописано. И даже можно имея новую версию glibc скомпилироваться и слинковаться для старой версии glibc. Проблемы будут только с компилятором, который будет требовать наличия свежих имплементаций служебных функций. Но если взять более старый компилятор и накрутить пару флагов, то всё получается.
Собственно, glibc одна из немногих библиотек, которые реально используют фичу с различными версиями API в одной библиотеке. Кроме них только пара-тройка низкоуровных системных библиотек так заморачивается, а все остальные тупо добавляют версию в имя библиотеки и не парятся.
Можно, но только на заводе и чтобы разъём был одним контактом на полюс. В автомобилях жгуты отлично работают, но они заводской опрессовки и с разъёмами на дурные токи.
Даже не обязательно по одному проводу. Можно и жгут, но запресованный на обоих концах в заводских условиях и нормированный по току. В автомобилях вполне себе жгуты на сотни ампер применяются и никаких проблем нет.
Если переходное сопротивление разъёма нормируется с допуском в четыре раза между минимум-максимумом (а это вполне нормально), то на предельных мощностях токи тоже будут в три четыре раза между проводниками различаться. Что мы имеем. Сделать разъём, у которого сопротивление нормируется в очень узком диапазоне, это та ещё задача. И её, кстати, нельзя решить в бытовых условиях, так как там нужна чистка и обработка разъёма при перестыковке. И конструкция пина там тоже очень сложная получается.
У вас всё сводится к тому, что нельзя использовать goto потому, что вы не умеет писать корректный код и правильно использовать имеющиеся в языке инструменты. Ну, не умеете, не используйте, кто ж принуждает-то. Только таким образом вам вообще ничего нельзя использовать потому, что так можно про любую сложную языковую конструкцию/концепцию. А вообще, есть алгоритмы, где без goto код получается крайне запутанный и неэффективный. Например, это алгоритм потокового преобразования байтов, где ещё и скорость важна.
Как вам уже сказали, результат получается мягко говоря сомнительный. Но кроме того ещё и стоимость разработки получается в 4 раза больше. Так как JavaFx GUI у вас реально два человека могу пилить (плюс тестировщики периодически), а ваш WEB нужно три команды - фронт, бэк и инфраструктура. Плюс чуваки, которые этим рулят. Плюс чуваки которые это всё под конкретные платформы адаптируют.
И получается, что 4х расходов на разработку, это сильно оптимистичный минимум. И это при крайне странном результате, с огромным тормозящим ненантивным приложением.
JavaFx его приемник. Qt ещё есть, но там всё очень сильно дорого выходит, а потому для особых случаев.
А на чём вы собрались писать серьёзные GUI под десктоп?
Оно ОЧЕНЬ портабельное, быстрое и правильной готовке имеет разумный размер. Плюс куча всяких библиотек. Серьёзное приложение на Compose мучительно писать. Как и на Tauri, который под капотом WEB-приложение.
Но процесс их синтеза из неорганики может быть настолько сложен, что вероятность его осуществления в количествах, достаточных для наблюдения без наличия жизни можно считать нулевой.
Вот только правильно говорить "из текущего понимания пространства-времени", так как никакого реального понимания и рядом нет.
Соответственно, пока что никто и ничто не запрещает мечтать о технологиях, позволяющих это самое пространство и/или время менять, обходя ограничение скорости света.
То что такое "в природе не встречается" не означает, что это невозможно. На Земле уже и без того масса всего есть, что "в природе" встретить нельзя - только как результат деятельности жизни, иногда только разумной жизни.
Вполне себе можно допустить наличие всяких свёрнутых измерений, симметрии времени и ещё черте-чего, чего современная физика не запрещает, просто подтверждающих наблюдений нет (со временем и вовсе сплошная загадка и всё только на эмпирических наблюдениях держится).
Они не могут. Они получали финансирование на разработку от Минобороны и Минобороны благополучно засекретило результаты.
В "большом коллективе", нужно уметь работать с этим самым коллективом и иметь стандарты разработки. Иначе важи джуны соврешненно на любом языке дичь напишут. Причём опыт показывает количество дичи не особо зависит от сложности языка, просто дичь будет в структуре кода, а не в goto, но потом найти на этапе тестирования найти эту дичь будет точно так же сложно.
А вас ничего в таком подходе не смущает? Вместо того, чтобы учить, вы активно распространяете чушь.
Оно даже веселее. Использование иностранных мессенджеров запрещено для госучреждений. То или создать бот могла только частная контора, или это нарушение закона. В случае частной компании тоже нарушение закона, кстати, так как её никто не упономачивал. В любом случае получается нарушение закона.
Но вообще говоря, я уверен, что бота создали в ФСБ. У них уже давно есть куча наработок по мониторинговым ботам для деанонимизации пользователей путём сопоставления информации из разный телеграм-каналов. И они угрозами их активно пихали примерно везде. Примерно в половине "новостных" каналов из боты стоят. Но вторая половина оставалась неокученной. А тут такая возможность - обазять ставить бота во все каналы и давать ему админство. А я всё ждал, когда и как они своё поделие начнут заставлять в обязательном порядке ставить.
Интересно, насколько именно шифрование по ГОСТ медленнее стандартного, учитывая что обычное шифрование всем миром правят и оптимизируют, а внутри там зачастую вообще аппаратно-поддерживаемый AES, который ГОСТу Боженька запретил использовать, дав в наказание всякую содранную с DES ущербность.
Я думаю, что ГОСТ примерно на порядок более ресурсоёмким окажется. Но может и больше.
Ха! И нужно будет шайбы и гроверы подкладывать и с нормированным усилием затягивать. В шаловливых руках пользователя гореть будет пуще прежнего.
А точно плёночная клавиатура, а не механические кнопки, накрытые толстой плёнкой? Судя по виду (индикатор довольно далеко отнесёт от стекла), там вполне может плата с обычными кнопками со штырьками.
Новые версии JVM уже всё это порешали. Причём именно основываясь на опыте китайцев. Из принципиального осталось улучшить поддержку наследования примитивных типов и избавиться от boxing/unboxing. И тестовых фичах это даже уже есть и работает, но там сложные вопросы с обратной совместимостью и с языками, использующими JVM, так процесс займёт некоторое время.
А остальное уже вполне себе сделано не хуже, чем у всех остальных.
У ELF-файлов есть возможность поддерживать различные таблицы экспорта для различных версий API. И потом при линковке указывать необходимую версию, которая будет выбираться рантайм при связывании загружаемых библиотек.
Сильно геморно и никто этим особенно не заморачивается, но glibc заморачивается. В результате glibc вполне неплохо умеет эмулировать старые версии API самого себя - там по несколько вариантов реализации некоторых функций прописано.
И даже можно имея новую версию glibc скомпилироваться и слинковаться для старой версии glibc. Проблемы будут только с компилятором, который будет требовать наличия свежих имплементаций служебных функций. Но если взять более старый компилятор и накрутить пару флагов, то всё получается.
Собственно, glibc одна из немногих библиотек, которые реально используют фичу с различными версиями API в одной библиотеке. Кроме них только пара-тройка низкоуровных системных библиотек так заморачивается, а все остальные тупо добавляют версию в имя библиотеки и не парятся.
Не факт, что это плёночная. Часто ставят механические кнопки, накрытые плёнкой - самое нормальное решение.
Можно, но только на заводе и чтобы разъём был одним контактом на полюс. В автомобилях жгуты отлично работают, но они заводской опрессовки и с разъёмами на дурные токи.
Даже не обязательно по одному проводу. Можно и жгут, но запресованный на обоих концах в заводских условиях и нормированный по току. В автомобилях вполне себе жгуты на сотни ампер применяются и никаких проблем нет.
Если переходное сопротивление разъёма нормируется с допуском в четыре раза между минимум-максимумом (а это вполне нормально), то на предельных мощностях токи тоже будут в три четыре раза между проводниками различаться. Что мы имеем. Сделать разъём, у которого сопротивление нормируется в очень узком диапазоне, это та ещё задача. И её, кстати, нельзя решить в бытовых условиях, так как там нужна чистка и обработка разъёма при перестыковке. И конструкция пина там тоже очень сложная получается.
У вас всё сводится к тому, что нельзя использовать goto потому, что вы не умеет писать корректный код и правильно использовать имеющиеся в языке инструменты. Ну, не умеете, не используйте, кто ж принуждает-то.
Только таким образом вам вообще ничего нельзя использовать потому, что так можно про любую сложную языковую конструкцию/концепцию.
А вообще, есть алгоритмы, где без goto код получается крайне запутанный и неэффективный. Например, это алгоритм потокового преобразования байтов, где ещё и скорость важна.