По мне вообще не какое-то особое открытие. Просто совпадает с разложением арксинуса (или чего уж там?) в ряд, не знаю уж, очень давно ли оно известно, но что в первой половине прошлого века знали — наверняка. Насколько понимаю, все неарифметические функции с помощью рядов и переводятся в команды процессора.
А вот про алгоритм Гровера могу сказать, что для меня это было самое понятное его изложение, какое когда-либо мне попадалось. Полагаю, его (алгоритма) практическое применение уже в ближайшие годы начнётся.
Хорошо, если наконец-то добавили. А то для Singularity, пусть в немного другом виде, оно сколько лет было, а в массы не шло. Несколько лет было, что в Swift возможность уже была, а в C# — когда-нибудь.
Но вот если б в C# ещё б аналогичным образом ввели возможность делать обязательным throws — вот это было б дело, а то в нём часто приходится на всякий случай ставить catch на всё, ибо типичная реальная ситуация с документацией хорошо известна. Конечно, у C# со структурами всегда были неудобства в плане их изменяемости. Но по сравнению с Swift как минимум преимущество — возможность объявления атрибутов. Классический синтаксис мне всё ж больше нравится. Ну и с пространствами имён удобнее, хотя с ними плохо стыкуются typealias/using ... =. Ну и PLINQ — преимущество C#, Swift для параллельной обработки ничего лучше closure пока не предлагает.
Я допускаю, что Kotlin и, может, и ещё какой-то язык программирования это умеют. Я не знаток Kotlin, но слышал, что он основан на JVM, в котором, если не путаю, не предусмотрено возможности объявления структур. На мой взгляд, это большое упущение, а вот в каком языке программирования эти возможности одновременно присутствуют? К тому ж, не знаю насколько так, но слышал, что в Kotlin ключевое слово throws не является обязательным. Если это так, по мне это плохо. Кстати, я всегда это называл главным недостатком C#.
Если бы всё было так просто… В Swift есть ТРИ (четыре?) разных вида рефлексии
Именно об этом я и упомянул кратко. Для CoreData всё равно нужен NSObject, так что там можно через selector'ы делать. Для JSON и впрямь ситуация оставлят желат лучшего, тем более, что объявления атрибутов нет, в Java и C# обычно ими и пользуются.
Во первых, это наверняка можно реализовать без Enum (не пробовал, в голову приходят абстрактный тип с наследниками)
Тогда в абстрактный может пойти лишь статус, ибо если объявить метод getError, в наследуемом классе его уже не спрятать, хотя, Java (в отличие от C#) позволяет protected метод сделать public. Но даже если так, это надо знать, к какому типу данных приводить в каждом случае, а если кто-то захотел что-то поменять в этих классах, да ещё так, что где-то возвращает null...
во вторых лично мне не нравится такой подход из-за того, что он провоцирует божественный метод-свалку c switch..case, в который запихнуто всё
Любую полезную возможность можно использовать во вред, что уж говорить...
Ваш конкретный пример — я бы посоветовал посмотреть на RxSwift или ReactiveX
Ну это, наверно, неудачный пример. Добавляем loading, recovering и прочее, и уже не всегда будет нужная реализация. Кстати, RxSwift результат выражает именно через enum с параметрами.
Что selector'ов нет у всего, что не наследуется от NSObject, это, конечно, плохо, согласен. И что в protocol теперь только обязательные функции объявлять можно.
Но с другой стороны, какой ещё язык программирования позволяет запретить передавать пустые указатели в compile time? Насколько знаю, optional в Java — решение лишь отчасти, позволяет лишь приделать костыль. А какой ещё язык программирования будет следить вот так:
class Something {
var someURL: URL
var someData: Data//допустим, это добавли позже
init(someURL: URL) {
self.someURL = someURL//нет, не компилируется, забыть инициализровать someData не получится
}
}
Ещё очень полезная вещь — enum с параметрами.
enum SomeResult {
case valid(data: Data)
case failure(error: Error)
}
Результат и ошибка одновременно не получатся никак. А ещё, в отличие от Java, структуры объявлять можно, и управлять их изменяемостью. Где ещё так? Хоть недостатков у Swift тоже немало, например, нет объявления атрибутов.
Они действительно были (не могу про WinForms писать в настоящем времени) перенесены в Mono… ну тот который последний выпущенный Moonlight поддерживал, совместимый с третьим Silverlight. Но эх и висючими они получались! Под Linux тогда никакие приложения не работали как медленно, как WinForms, это было вроде эмуляции Windows Vista, он не столь давним в те годы был. Так что если уж под Linux нужно с .Net — так сколько помню, всегда был GTK#, позже появился его межплатформенный аналог XWT.
А вот интересно, почему не сделают так: допустим, существует какой-то государственный реестр мобильных устройств, пусть даже с добровольной регистрацией. А само мобильное устройство содержит неизменяемый секретный ключ с аппаратной защитой, который никогда программно не отдаёт, но может выдавать его открытый ключ и выполнять подпись. При регистрации в этот реестр включается открытый ключ. Те ж банки, скажем, по каким-то запросам могут его получить. А для авторизации требуются не просто биометрические данные, а подписанные этим ключом. Если данные на устройстве не хранятся, то даже его потеря не позволяет мгновенно получить доступ. А сами биометрические данные тогда и вовсе ничего не дадут.
Есть, конечно, риск перехвата всего сообщения через какой-то подставной Wi-Fi. Но можно рассматривать точную копию как подозрительный запрос с ответом на повторную авторизацию. В общем, от явных уязвимостей защита находится, а абсолютно надёжного ничего не бывает. Ну а если кто не хочет регистрировать, рискует на своё усмотрение.
Вот только, насколько знаю, в большинстве устройств ничего полностью подходящего под эти критерии нет. Интересно, почему ничего такого всё ещё не создали.
Мне вот тоже интересно. Тем более я сам как-то делал .Net в Docker'е, хоть тот проект production-версии так и не увидел в итоге. Про РЖД я понял лишь примерно, что у них как, а я делал через внутреннюю сеть контейнеров, открывая наружу только NGINX, всё остальное через него. Просто даже стало интересно, какие в этом случае могли остаться уязвимости.
Кстати, тогда в состоянии pre-production я видел log'и NGINX'а и попытки получить оттуда всякие PHP'ные файлы, коих там и не было.
Соглашусь только с последним пунктом. По мне всякая необходимость оставлять неиспользуемые функции полностью исчезла с появлением Git.
А вот на счёт остального скажу — такие рекомендации и без того часто понимают превратно. Вообще, много раз убеждался, что любую разумную идея можно довести до абсурда. И особенно могу сказать про первые два пункта, во что это скорее всего превратится в реальности. Умельцев внедрят функциональность самым примитивным способом хоть отбавляй. После этого соответствующие задачи переходят в статус выполнено и включать в очередной sprint время на refactoring редко кто топорится. Вместо этого реализуется дальнейшая функциональность со всё новыми костылями. В итоге очередную новую функцию становится нереально в сколь-нибудь сопоставимые сроки реализовать без новых костылей, как ни хотелось б. Ну и далее характерный реальзтат, когда исправление одной ошибки создат другую ошибку.
Я как-то писал такой. Только ползунки сразу сделал не слоями, а view — тогда их можно сделать в конкретном приложении совершенно любого вида, простейший вариант будет — UIImage со значком из xcassets. И к тому ж предпочитаю меньше графики и большей слоёв — даже у CALayer есть куча свойств для отображения, а есть еш наследованные от него класс.
У меня аналогичный вопрос возник. Вряд ли проблема в принципе получить кислород из углекислого газа. Но что делать, если для начала и его мало. А кислорода по массе и того меньше останется, что ж восполнит атмосферное давление. А если на марсе и с азотом туго, то и впрямь особенно ничем не восполнить. А при низком атмосферном давлении без скафандра будет всё равно наружу не выйти.
Смотря в какой момент. Давным давно, когда iPhone ещё не было, start-up'ы по смартфонам выглядели перспективно. А уже лет 6 назад можно было сказать, что рынок смартфонных ОСей поделён между Apple и Google и больше там никого не ждут. Аналогично и с нейронными сетями: всё полезное или уже в составе Android SDK и iOS SDK, или скоро будет. А остальное практического применения в обозримом будущем не найдёт.
Так до сих пор и не собрался изучить этот вопрос, но слышал ещё года 2 назад, что что-то появилось. Вот только догадываюсь, что это только может быть про Java SE/ME (Java EE ведь больше нет, или я ошибаюсь), но не про Android SDK.
К нейронным сетям я всегда относился достаточно скептически. И даже тут писал идеи. Впрочем, с дальнейшим развитием у меня пока что не очень, да и упомянутый вариант я решил немного поменять, но лишь едва начинал его. Раз уж о том речь, скажу, что за вариант. Так и не удалось собрать из исходников Phrasal. Это такое open source'ное подобие Google-перевода.
Ну и даже приведу пространные рассуждения о том, причём тут Phrasal и Google-перевод. Методы выявления N-грамм и предполагаемые методы выявления денотатов — почти одно и то же. Phrasal в комплекте содержит инструменты обработки естественно-языкового текста со структурой данных на выходе, из которой можно получить данные о корреляции между словами. Дальше дело за применением кластеризации или ещё каких методов, которые более или менее правдоподобно выявят денотаты. Ну и дальше ещё чуть о моих попытках. В тот период, как я с этим ковырялся, более удобный open source'ный аналог Google-перевода я так и не нашёл. Когда вернусь к этому вопросу, может ещё раз проверю, что из этого ещё есть.
И немного ещё моего мнения о нейронных сетях. Слышал, что в авиации от их применения отказались, и считаю, что правильно сделали. И полагаю, что их применение — лишь самый простой способ сделать систему, которая хоть как-то работает. Но возможности улучшения нейронных сетей по многим задачам, на мой взгляд, ограничены.
Beta-версия? Ну, может, через годик-другой release будет. А лет через 5 в какой-то beta-версии решат проблему изменяемости структур. Если, конечно, вообще в таком виде C# останется кому-т ещ интересен. Кстати, это в Core убдет тоже, или только под мало кому нужный немежплатформенный Framework. C# от Swift, видать, отстал уже безнадёжно, уже и от Java остаёт.
По мне вообще не какое-то особое открытие. Просто совпадает с разложением арксинуса (или чего уж там?) в ряд, не знаю уж, очень давно ли оно известно, но что в первой половине прошлого века знали — наверняка. Насколько понимаю, все неарифметические функции с помощью рядов и переводятся в команды процессора.
А вот про алгоритм Гровера могу сказать, что для меня это было самое понятное его изложение, какое когда-либо мне попадалось. Полагаю, его (алгоритма) практическое применение уже в ближайшие годы начнётся.
Хорошо, если наконец-то добавили. А то для Singularity, пусть в немного другом виде, оно сколько лет было, а в массы не шло. Несколько лет было, что в Swift возможность уже была, а в C# — когда-нибудь.
Но вот если б в C# ещё б аналогичным образом ввели возможность делать обязательным
throws— вот это было б дело, а то в нём часто приходится на всякий случай ставитьcatchна всё, ибо типичная реальная ситуация с документацией хорошо известна. Конечно, у C# со структурами всегда были неудобства в плане их изменяемости. Но по сравнению с Swift как минимум преимущество — возможность объявления атрибутов. Классический синтаксис мне всё ж больше нравится. Ну и с пространствами имён удобнее, хотя с ними плохо стыкуютсяtypealias/using ... =. Ну и PLINQ — преимущество C#, Swift для параллельной обработки ничего лучше closure пока не предлагает.Я допускаю, что Kotlin и, может, и ещё какой-то язык программирования это умеют. Я не знаток Kotlin, но слышал, что он основан на JVM, в котором, если не путаю, не предусмотрено возможности объявления структур. На мой взгляд, это большое упущение, а вот в каком языке программирования эти возможности одновременно присутствуют? К тому ж, не знаю насколько так, но слышал, что в Kotlin ключевое слово
throwsне является обязательным. Если это так, по мне это плохо. Кстати, я всегда это называл главным недостатком C#.Именно об этом я и упомянул кратко. Для CoreData всё равно нужен NSObject, так что там можно через selector'ы делать. Для JSON и впрямь ситуация оставлят желат лучшего, тем более, что объявления атрибутов нет, в Java и C# обычно ими и пользуются.
Тогда в абстрактный может пойти лишь статус, ибо если объявить метод
getError, в наследуемом классе его уже не спрятать, хотя, Java (в отличие от C#) позволяет protected метод сделать public. Но даже если так, это надо знать, к какому типу данных приводить в каждом случае, а если кто-то захотел что-то поменять в этих классах, да ещё так, что где-то возвращаетnull...Любую полезную возможность можно использовать во вред, что уж говорить...
Ну это, наверно, неудачный пример. Добавляем
loading,recoveringи прочее, и уже не всегда будет нужная реализация. Кстати, RxSwift результат выражает именно через enum с параметрами.Что selector'ов нет у всего, что не наследуется от NSObject, это, конечно, плохо, согласен. И что в protocol теперь только обязательные функции объявлять можно.
Но с другой стороны, какой ещё язык программирования позволяет запретить передавать пустые указатели в compile time? Насколько знаю, optional в Java — решение лишь отчасти, позволяет лишь приделать костыль. А какой ещё язык программирования будет следить вот так:
Ещё очень полезная вещь — enum с параметрами.
Результат и ошибка одновременно не получатся никак. А ещё, в отличие от Java, структуры объявлять можно, и управлять их изменяемостью. Где ещё так? Хоть недостатков у Swift тоже немало, например, нет объявления атрибутов.
Причём и Яндекс давно понимает такой запрос. Разве что, скажем, descargar для него пока что просто слово.
Они действительно были (не могу про WinForms писать в настоящем времени) перенесены в Mono… ну тот который последний выпущенный Moonlight поддерживал, совместимый с третьим Silverlight. Но эх и висючими они получались! Под Linux тогда никакие приложения не работали как медленно, как WinForms, это было вроде эмуляции Windows Vista, он не столь давним в те годы был. Так что если уж под Linux нужно с .Net — так сколько помню, всегда был GTK#, позже появился его межплатформенный аналог XWT.
Но получается, нужен hash, для которого возможно приблизительное сравнение. Впрочем, от чего не существовать таким алгоритмам.
А вот интересно, почему не сделают так: допустим, существует какой-то государственный реестр мобильных устройств, пусть даже с добровольной регистрацией. А само мобильное устройство содержит неизменяемый секретный ключ с аппаратной защитой, который никогда программно не отдаёт, но может выдавать его открытый ключ и выполнять подпись. При регистрации в этот реестр включается открытый ключ. Те ж банки, скажем, по каким-то запросам могут его получить. А для авторизации требуются не просто биометрические данные, а подписанные этим ключом. Если данные на устройстве не хранятся, то даже его потеря не позволяет мгновенно получить доступ. А сами биометрические данные тогда и вовсе ничего не дадут.
Есть, конечно, риск перехвата всего сообщения через какой-то подставной Wi-Fi. Но можно рассматривать точную копию как подозрительный запрос с ответом на повторную авторизацию. В общем, от явных уязвимостей защита находится, а абсолютно надёжного ничего не бывает. Ну а если кто не хочет регистрировать, рискует на своё усмотрение.
Вот только, насколько знаю, в большинстве устройств ничего полностью подходящего под эти критерии нет. Интересно, почему ничего такого всё ещё не создали.
Мне вот тоже интересно. Тем более я сам как-то делал .Net в Docker'е, хоть тот проект production-версии так и не увидел в итоге. Про РЖД я понял лишь примерно, что у них как, а я делал через внутреннюю сеть контейнеров, открывая наружу только NGINX, всё остальное через него. Просто даже стало интересно, какие в этом случае могли остаться уязвимости.
Кстати, тогда в состоянии pre-production я видел log'и NGINX'а и попытки получить оттуда всякие PHP'ные файлы, коих там и не было.
Кстати, сколько помню, стандартный
joined, который для стоковогоSequence, у меня в Xcode ни разу не выводился для коллекций других типов.Соглашусь только с последним пунктом. По мне всякая необходимость оставлять неиспользуемые функции полностью исчезла с появлением Git.
А вот на счёт остального скажу — такие рекомендации и без того часто понимают превратно. Вообще, много раз убеждался, что любую разумную идея можно довести до абсурда. И особенно могу сказать про первые два пункта, во что это скорее всего превратится в реальности. Умельцев внедрят функциональность самым примитивным способом хоть отбавляй. После этого соответствующие задачи переходят в статус выполнено и включать в очередной sprint время на refactoring редко кто топорится. Вместо этого реализуется дальнейшая функциональность со всё новыми костылями. В итоге очередную новую функцию становится нереально в сколь-нибудь сопоставимые сроки реализовать без новых костылей, как ни хотелось б. Ну и далее характерный реальзтат, когда исправление одной ошибки создат другую ошибку.
Я как-то писал такой. Только ползунки сразу сделал не слоями, а view — тогда их можно сделать в конкретном приложении совершенно любого вида, простейший вариант будет — UIImage со значком из xcassets. И к тому ж предпочитаю меньше графики и большей слоёв — даже у CALayer есть куча свойств для отображения, а есть еш наследованные от него класс.
В условиях планеты можно для этой цели задействовать цианобактерии. Но при низкой плотности атмосферы толку от этого не будет.
У меня аналогичный вопрос возник. Вряд ли проблема в принципе получить кислород из углекислого газа. Но что делать, если для начала и его мало. А кислорода по массе и того меньше останется, что ж восполнит атмосферное давление. А если на марсе и с азотом туго, то и впрямь особенно ничем не восполнить. А при низком атмосферном давлении без скафандра будет всё равно наружу не выйти.
А кому интересно, "досталас" проксима-центавра? Тем более, там вроде недавно вторую планету нашли. Или тау-кита кому?
Смотря в какой момент. Давным давно, когда iPhone ещё не было, start-up'ы по смартфонам выглядели перспективно. А уже лет 6 назад можно было сказать, что рынок смартфонных ОСей поделён между Apple и Google и больше там никого не ждут. Аналогично и с нейронными сетями: всё полезное или уже в составе Android SDK и iOS SDK, или скоро будет. А остальное практического применения в обозримом будущем не найдёт.
Так до сих пор и не собрался изучить этот вопрос, но слышал ещё года 2 назад, что что-то появилось. Вот только догадываюсь, что это только может быть про Java SE/ME (Java EE ведь больше нет, или я ошибаюсь), но не про Android SDK.
К нейронным сетям я всегда относился достаточно скептически. И даже тут писал идеи. Впрочем, с дальнейшим развитием у меня пока что не очень, да и упомянутый вариант я решил немного поменять, но лишь едва начинал его. Раз уж о том речь, скажу, что за вариант. Так и не удалось собрать из исходников Phrasal. Это такое open source'ное подобие Google-перевода.
Ну и даже приведу пространные рассуждения о том, причём тут Phrasal и Google-перевод. Методы выявления N-грамм и предполагаемые методы выявления денотатов — почти одно и то же. Phrasal в комплекте содержит инструменты обработки естественно-языкового текста со структурой данных на выходе, из которой можно получить данные о корреляции между словами. Дальше дело за применением кластеризации или ещё каких методов, которые более или менее правдоподобно выявят денотаты. Ну и дальше ещё чуть о моих попытках. В тот период, как я с этим ковырялся, более удобный open source'ный аналог Google-перевода я так и не нашёл. Когда вернусь к этому вопросу, может ещё раз проверю, что из этого ещё есть.
И немного ещё моего мнения о нейронных сетях. Слышал, что в авиации от их применения отказались, и считаю, что правильно сделали. И полагаю, что их применение — лишь самый простой способ сделать систему, которая хоть как-то работает. Но возможности улучшения нейронных сетей по многим задачам, на мой взгляд, ограничены.