Способа применить научный метод при разработке или проектировании я пока что не вижу (но буду рад, если подскажут, как можно это сделать). При анализе техзадания его неявно применяли и раньше. Например, если что-нибудь в задании непонятно — строишь гипотезу, описываешь её, и направляешь постановщику задач. В зависимости от того, подтверждает он гипотезу или нет, можно делать дальнейшие выводы о задаче.
(Задания бывают очень сложные и мутные настолько, что прямые вопросы "как должно работать то или другое" постановщику ставить бесполезно, и приходится строить вместе с ним такие вот мысленные эксперименты, чтобы понять, как должен работать софт. Вообще говоря, эта проблема может быть на корню решена с помощью DDD, но пока его внедряют не везде.)
До применения научного метода чинили баги так — тут пошаманим, там пошаманим, починилось — и славно. Теперь строим гипотезы, проверяем, строим дальнейшие, и таким образом всегда докапываемся до истины.
Объективной статистикой не владею, но субъективно могу сказать, что раньше отладка могла занимать в среднем O(n) от количества возможных действий по починке бага, а теперь O(log n).
Практическая разница не сильная (то есть не на порядок), но уверенность в результатах своих действий стала намного выше. Стало ли в действительности меньше переоткрытых багов — опять-таки, объективно сказать не могу, простите. Подобного рода статистикой не занимались.
Депрекейтить необязательно, достаточно только лишь подробно рассмотреть вопрос. У функции WriteConsoleA есть вполне определённое поведение: вывести строку в текущей OEM-кодировке (ну, вообще говоря, просто в текущей кодировке консоли в соответствии с SetConsoleOutputCP, которая по умолчанию инициализируется из OEM).
Если конкретному приложению нужно именно это (мне сложно представить себе современное приложение с такими нуждами, но мало ли) — оно вполне легитимно вправе использовать это семейство функций.
Если же конкретное приложение хочет выводить какой-то национальный текст вне зависимости от кодировки терминала — оно должно использовать соответствующие юникодовые функции (a la WriteConsoleW). Вот и всё.
приложение, которое выводит на stdout интерактивный контент не в том, что указано в переменных локализации LC_*, надо исправлять, а не жить с этим. Это — ошибка, а не нормальное поведение.
В этом я с вами тоже полностью согласен! Приложения, которые пытаются использовать функции семейства WriteConsoleA (которые по определению работают в текущей OEM-кодировке), чтобы выводить текст в другой кодировке, тоже надо исправлять. В Windows, если вам угодно, переменные локализации LC_* всегда константы и указывают UTF-16 кодировку, для которой есть соответствующее семейство функций вывода на экран. К сожалению, многие программы это игнорируют и пытаются совать в OEM-функции тексты в своих кодировках, что иногда и вызывает проблемы.
если очень нужно — большинство эмуляторов терминала умеют установить произвольную кодировку в качестве отображаемой, в том числе варианты UTF16.
А это не испортит вывод предыдущих команд в том же терминале? Пожалуй, для каких-то единичных программ всё-таки лучше пайпать их вывод в iconv.
PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Да, конечно, вы правы. И поэтому так такой совместимости по умолчанию и не предусмотрено: приложения, которые пользуются современными юникодовыми API (WriteConsoleW), будут печатать вывод нормально, а для устаревших приложений нужны бубны (некоторые сорта которых описаны в посте). К сожалению, приложений, которые не пользуются современными юникодовыми API, ещё очень много. Многие рантаймы языков программирования также этот режим вывода не поддерживают, что ещё печальнее.
А в линуксе как вы будете запускать программу, которая выводит UTF-16 в stdout, и чтоб этот текст отобразился на терминале?
(Я не утверждаю, что вы не сможете это сделать, просто мне действительно интересно посмотреть на решение.)
Примеры кода, кажется, на обычном ES2016 (или какой там сейчас, уже 2017?) — стрелочные функции, классы, декораторы. Не то чтобы совсем каждодневные фичи, конечно, но и без особой экзотики.
Ну, вообще говоря, пока что виноват тулинг, который подводит. Собственно, тулинг для .NET Core сейчас в состоянии preview и находится, и его переделывают. А вот сам по себе рантайм и библиотеки в полном порядке, у меня работают в продакшене.
Но вы, конечно же, правы, это не то качество продукта, к которому мы привыкли. Пока что в полной комплектации он и не рекомендуется для полноценного использования (потому что инструменты сборки в preview).
И тем не менее, утверждение, которое я опровергаю, строго неверно. CLR сегодня запускается под основными платформами, будь то альфа-качество или нет. И, да, я осознаю, что в те времена, когда принималось решение о прекращении поддержки ScalaCLR, состояние дел было несколько иным. Более того — если это позволило перекинуть больше ресурсов на основную ветку разработки Scala, то я этому даже рад.
Я не квалифицирован достаточно, чтобы отвечать на ваш вопрос, но попробую просто в виде примера показать, как ФП может помочь решать задачи из реального мира.
Есть такая штука — SSIS. По жизни штуковина довольно сложная, и вызывающая множество проблем и боли у разработчиков, которые её пытаются использовать для каких-то прикладных задач (а она действительно бывает нужна, просто поверьте пока что на слово). Итак, разработчики плачут, колются, но продолжают пожирать кактус с полуимперативными действиями по деплойменту и настройке SSIS-пакетов, воюют с разными версиями IDE, серверов и прочей дребеденью.
И тут появляется Chimayo. С использованием сравнительно небольшого количества паттернов функционального языка она позволяет описывать эти SSIS-задачи, формировать их в функциональном стиле, манипулировать как значениями первого класса, ну и всё такое. В общем, позволяет избавиться от боли и начать программистам, наконец, программировать.
К чему я это сказал? Я думаю, что для вашей инициализации UEFI просто не написан (или пока что вам не встретился) подходящий декларативный инструмент, использующий современные достижения функционального программирования. Если б он был — поверьте, вам бы понравилось, как и нам понравилось работать с Chimayo после ада ручной настройки SSIS.
А посмотрите, интересно получается. Цитата из статьи:
Группа три находится на пороге входа в мэйнстрим, с большой поддержкой со стороны Mozilla (Rust) и Apple (Swift).
Получается, сюда надо добавить ещё Microsoft и Facebook (вроде бы, они очень активно применяют у себя OCaml — во всех этих новомодных Flow и Reason).
То есть нас почти вся индустрия затягивает — используйте функциональные языки, используйте. А мы (не все, но как минимум некоторые) старательно отнекиваемся ,)
С точки зрения теории типов ваш T равномощен множеству всех возможных функций void () (то есть функций, не принимающих и не возвращающих никаких объектов).
Способа применить научный метод при разработке или проектировании я пока что не вижу (но буду рад, если подскажут, как можно это сделать). При анализе техзадания его неявно применяли и раньше. Например, если что-нибудь в задании непонятно — строишь гипотезу, описываешь её, и направляешь постановщику задач. В зависимости от того, подтверждает он гипотезу или нет, можно делать дальнейшие выводы о задаче.
(Задания бывают очень сложные и мутные настолько, что прямые вопросы "как должно работать то или другое" постановщику ставить бесполезно, и приходится строить вместе с ним такие вот мысленные эксперименты, чтобы понять, как должен работать софт. Вообще говоря, эта проблема может быть на корню решена с помощью DDD, но пока его внедряют не везде.)
До применения научного метода чинили баги так — тут пошаманим, там пошаманим, починилось — и славно. Теперь строим гипотезы, проверяем, строим дальнейшие, и таким образом всегда докапываемся до истины.
Объективной статистикой не владею, но субъективно могу сказать, что раньше отладка могла занимать в среднем O(n) от количества возможных действий по починке бага, а теперь O(log n).
Практическая разница не сильная (то есть не на порядок), но уверенность в результатах своих действий стала намного выше. Стало ли в действительности меньше переоткрытых багов — опять-таки, объективно сказать не могу, простите. Подобного рода статистикой не занимались.
Мы с коллегами постоянно применяем научный метод для отладки и разработки приложений. Вдохновил нас вот этот доклад: Debugging with the Scientific Method — Stuart Halloway.
(Не смотрите, что доклад на канале Clojure — он и в самом деле вполне себе обобщается на другие технологии.)
Депрекейтить необязательно, достаточно только лишь подробно рассмотреть вопрос. У функции
WriteConsoleAесть вполне определённое поведение: вывести строку в текущей OEM-кодировке (ну, вообще говоря, просто в текущей кодировке консоли в соответствии сSetConsoleOutputCP, которая по умолчанию инициализируется из OEM).Если конкретному приложению нужно именно это (мне сложно представить себе современное приложение с такими нуждами, но мало ли) — оно вполне легитимно вправе использовать это семейство функций.
Если же конкретное приложение хочет выводить какой-то национальный текст вне зависимости от кодировки терминала — оно должно использовать соответствующие юникодовые функции (a la
WriteConsoleW). Вот и всё.В этом я с вами тоже полностью согласен! Приложения, которые пытаются использовать функции семейства
WriteConsoleA(которые по определению работают в текущей OEM-кодировке), чтобы выводить текст в другой кодировке, тоже надо исправлять. В Windows, если вам угодно, переменные локализации LC_* всегда константы и указывают UTF-16 кодировку, для которой есть соответствующее семейство функций вывода на экран. К сожалению, многие программы это игнорируют и пытаются совать в OEM-функции тексты в своих кодировках, что иногда и вызывает проблемы.А это не испортит вывод предыдущих команд в том же терминале? Пожалуй, для каких-то единичных программ всё-таки лучше пайпать их вывод в
iconv.Да, конечно, вы правы. И поэтому так такой совместимости по умолчанию и не предусмотрено: приложения, которые пользуются современными юникодовыми API (
WriteConsoleW), будут печатать вывод нормально, а для устаревших приложений нужны бубны (некоторые сорта которых описаны в посте). К сожалению, приложений, которые не пользуются современными юникодовыми API, ещё очень много. Многие рантаймы языков программирования также этот режим вывода не поддерживают, что ещё печальнее.А в линуксе как вы будете запускать программу, которая выводит UTF-16 в stdout, и чтоб этот текст отобразился на терминале?
(Я не утверждаю, что вы не сможете это сделать, просто мне действительно интересно посмотреть на решение.)
Да, вы правы. Простите, при беглом просмотре не заметил несколько аннотаций типов тут и там.
Примеры кода, кажется, на обычном ES2016 (или какой там сейчас, уже 2017?) — стрелочные функции, классы, декораторы. Не то чтобы совсем каждодневные фичи, конечно, но и без особой экзотики.
Похоже, что проблему с форками уже починили — всё отображается правильно.
Немножко оффтоп, конечно, но я такую конструкцию видел в другом языке под JVM: в языке Frege (на Haskell похожий).
Ну, вообще говоря, пока что виноват тулинг, который подводит. Собственно, тулинг для .NET Core сейчас в состоянии preview и находится, и его переделывают. А вот сам по себе рантайм и библиотеки в полном порядке, у меня работают в продакшене.
Но вы, конечно же, правы, это не то качество продукта, к которому мы привыкли. Пока что в полной комплектации он и не рекомендуется для полноценного использования (потому что инструменты сборки в preview).
И тем не менее, утверждение, которое я опровергаю, строго неверно. CLR сегодня запускается под основными платформами, будь то альфа-качество или нет. И, да, я осознаю, что в те времена, когда принималось решение о прекращении поддержки ScalaCLR, состояние дел было несколько иным. Более того — если это позволило перекинуть больше ресурсов на основную ветку разработки Scala, то я этому даже рад.
Простите, но тут вы неправы. CLR официально поддерживается и запускается под другими ОС: https://www.microsoft.com/net/download/core
Воу, вот за генератор ресурсов спасибо.
Эх, а он у вас тоже только строковые ресурсы поддерживает, да? Никаких там
ImageListв него не запаковать? :("Не фунт изюму" — устойчивое выражение. Во всяком случае, я его слышал именно в таком варианте, через "у".
Это тот самый судья, который в прошлый раз не дал им отсудить несколько миллионов за тридцать строк кода?
Пруф: https://habrahabr.ru/post/143974/
Хотя, может, однофамилец.
Я не квалифицирован достаточно, чтобы отвечать на ваш вопрос, но попробую просто в виде примера показать, как ФП может помочь решать задачи из реального мира.
Есть такая штука — SSIS. По жизни штуковина довольно сложная, и вызывающая множество проблем и боли у разработчиков, которые её пытаются использовать для каких-то прикладных задач (а она действительно бывает нужна, просто поверьте пока что на слово). Итак, разработчики плачут, колются, но продолжают пожирать кактус с полуимперативными действиями по деплойменту и настройке SSIS-пакетов, воюют с разными версиями IDE, серверов и прочей дребеденью.
И тут появляется Chimayo. С использованием сравнительно небольшого количества паттернов функционального языка она позволяет описывать эти SSIS-задачи, формировать их в функциональном стиле, манипулировать как значениями первого класса, ну и всё такое. В общем, позволяет избавиться от боли и начать программистам, наконец, программировать.
К чему я это сказал? Я думаю, что для вашей инициализации UEFI просто не написан (или пока что вам не встретился) подходящий декларативный инструмент, использующий современные достижения функционального программирования. Если б он был — поверьте, вам бы понравилось, как и нам понравилось работать с Chimayo после ада ручной настройки SSIS.
Есть ещё https://www.ohaskell.guide/
А посмотрите, интересно получается. Цитата из статьи:
Получается, сюда надо добавить ещё Microsoft и Facebook (вроде бы, они очень активно применяют у себя OCaml — во всех этих новомодных Flow и Reason).
То есть нас почти вся индустрия затягивает — используйте функциональные языки, используйте. А мы (не все, но как минимум некоторые) старательно отнекиваемся ,)
И ещё, наверное, F#?
С точки зрения теории типов ваш
Tравномощен множеству всех возможных функцийvoid ()(то есть функций, не принимающих и не возвращающих никаких объектов).