Депрекейтить необязательно, достаточно только лишь подробно рассмотреть вопрос. У функции 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 () (то есть функций, не принимающих и не возвращающих никаких объектов).
Ну, функции на типах — это самая суть зависимой типизации и есть. Согласуется ли это с понятием коллекции — вопрос дискуссионный. Мой поинт в том, что современные языки с зависимыми типами оперируют вещами на уровне, достаточно близком к приведённым в статье (полу-) формальным определениям.
Мне кажется, вот в языках типа Idris, Agda и Coq так оно и есть. Там типы можно определять перечисляя все возможные значения, либо индуктивно. В любом учебнике вот так определяют натуральные числа:
Z : Nat // ноль — натуральное число
succ Nat : Nat // любое число, следующее за натуральным — натуральное
И получается, что множество натуральных чисел — это бесконечное множество {Z, succ Z, succ (succ Z), ...}.
Депрекейтить необязательно, достаточно только лишь подробно рассмотреть вопрос. У функции
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 ()(то есть функций, не принимающих и не возвращающих никаких объектов).Ну, функции на типах — это самая суть зависимой типизации и есть. Согласуется ли это с понятием коллекции — вопрос дискуссионный. Мой поинт в том, что современные языки с зависимыми типами оперируют вещами на уровне, достаточно близком к приведённым в статье (полу-) формальным определениям.
Мне кажется, вот в языках типа Idris, Agda и Coq так оно и есть. Там типы можно определять перечисляя все возможные значения, либо индуктивно. В любом учебнике вот так определяют натуральные числа:
И получается, что множество натуральных чисел — это бесконечное множество {
Z,succ Z,succ (succ Z), ...}.Истинно так, я тоже замечал.