Зачем нужен F#?

Вы не подумайте, что я злодей. Просто зачем нужен F#, если есть C# или хотя-бы VB.NET, в которых возможностей больше?

0

Сообщение от Shamil1 по какой-то причине

По причине односторонней видимости объявлений в F# пришлось рекурсию устраивать через коллбек.
bodyImpl нужно бы использовать в функции bracker, но возникает взаимная рекурсия через 3 функции. По этому применён костыль createParserForwardedToRef.
В коде на Haskell ниже в той теме, который я механически перенёс с F#, костыль не требуется.
На C# я парсек не пробовал, но оно есть.

0

Сообщение от Curry В коде на Haskell ниже в той теме

В коде на Хаскель Парсек когда компилируется? Вместе с Вашим кодом? А в коде на С# библиотеки уже скомпилированы.

0

Сообщение от Shamil1 В коде на Хаскель Парсек когда компилируется?

Когда пакет устанавливается. И когда компилируется, это тут не при чём.

0

Сообщение от Curry Когда пакет устанавливается. И когда компилируется, это тут не при чём.

Поправьте меня, если я не прав.

В F# эта функция имеет конкретный тип, вычисленный в момент компиляции. Если мы будем компилировать этот модуль отдельно, то получим что-то типа
Если мы будет компилировать этот модуль вместе с таким модулем:
то получим что-то типа:
В Haskell аналогичный модуль невозможно скомпилировать. Компилятор не может знать, какие машинные инструкции понадобятся.

0

Сообщение от Shamil1 В Haskell аналогичный модуль невозможно скомпилировать.

Можно. Но это уже оффтоп. Мне так кажется.

0

Сообщение от Curry Можно.

И в какие машинные инструкции скомпилируется add, если неизвестны типы x y и неизвестно, что за функция +?

0

Сообщение от Shamil1 То есть, его можно использовать для админских задач вместо (имхо неудобного) PowerShell

А можно пример админской задачи, которая с помощью REPL F# решалась бы удобнее, чем в оболочке powershell ?
Хотя бы один пример.
Пусть даже не полностью готовый.
Да чорт с ним, пусть даже совсем не готовый, а только самую идею.
А?

0

Сообщение от volodin661 А можно пример админской задачи, которая с помощью REPL F# решалась бы удобнее, чем в оболочке powershell ?

Решал задачу на PowerShell. Вывести то и вывести это. У меня две строчки кода - одна выводит то, другая выводит это. Но вторая ничего не выводит, если её поместить после первой. Если поменять местами, то обе выводят правильно. На F# такого не будет.
Плюс все эти неявные преобразования и прочие неявные вещи. ИМХО неудобный язык. Разве что копипастить и выполнять команды.

0

Shamil1,
То есть, примера не будет ?

Сообщение от Shamil1 ИМХО неудобный язык. Разве что копипастить и выполнять команды.

powershell ( здесь корень shell ), оболочка для выполнения команд ИЁХО неудобна, потому что в ней удобно
выполнять команды. Ну, понятно, да.

0

Сообщение от volodin661 powershell ( здесь корень shell ), оболочка для выполнения команд ИЁХО неудобна, потому что в ней удобно выполнять команды. Ну, понятно, да.

Вы неправильно поняли. "Оболочка для выполнения команд" неудобна для написания скриптов, кроме самых простых. При этом она позиционируется как решение для автоматизации задач, которое включает оболочку командной строки, скриптовый язык и платформу управления конфигурацией.

Сообщение от volodin661 То есть, примера не будет ?

Синхронизировать кастомную локализацию с изменениями ресурсов в патче.

0

То есть, 21 год хитрожопый Джеффри Сновер морочит голову крупной софтверной корпорации,
будучи сам в её рядах, потрачено два десятилетия и миллиард долларов, а на выходе что-то настолько
маловразумительное, что даже REPL вариант языка F# , который никто не собирался и не собирается использовать в качестве платформы для автоматизации, более удобен для подобных задач. Такое вот твоё ИМХО.

Сообщение от Shamil1 Синхронизировать кастомную локализацию с изменениями ресурсов в патче.

Ну и ? А дальше ? Где тут прокололся powershell и засиял F#?

Сообщение от Shamil1 "Оболочка для выполнения команд" неудобна для написания скриптов, кроме самых простых.

На текущий момент стратегия использования оболочки такова: вся тяжесть возложена на специализированные cmdlet,
которые из соображений производительности реализовываются на C#. Особых проблем в написании последних для нужд администрирования на собственно скрипте powershell нет никаких, архитектура и дизайн языка достаточны удобны.
( Отладчик, подсистема тестирования, модули, то, сё ... ).
Сам язык не является образцом совершенства, конечно же и даже отчасти вызывает раздражение, но, тем не менее, его возможности таковы, что никакого другого shell рядом даже стояло.

0

Сообщение от volodin661 Особых проблем в написании последних для нужд администрирования на собственно скрипте powershell нет никаких, архитектура и дизайн языка достаточны удобны.

Неудобно, когда результат выполнения строки кода зависит от наличия в коде других строк, на первый взгляд (и на второй) не имеющих никакого отношения к выполняемой строке.
Неудобно, когда без чтения документации нельзя понять, что возвращает функция.
Неудобно, когда язык выполняет неявные преобразования по сложному алгоритму. В общем случае, любой тип может превратить в любой тип. Чаще всего это происходит неожиданно и всплывает далеко, от места ошибки в коде.

Сообщение от volodin661 Ну и ? А дальше ? Где тут прокололся powershell и засиял F#?

На PowerShell писать неудобно, а на F# - удобно.

0

Сообщение от volodin661 его возможности таковы, что никакого другого shell рядом даже стояло

Зря вы мутите холивар PS vs F#, не взлетит. Это если PS сравнивать со скриптами, используемыми как командные пингвинами (bash; питон, даже). Вот тогда много всего будет лететь на вентилятор.

Насчёт PS, то я некогда пытался поработать через него с СОМ-объектом. Ничего не вышло. Знаю что с помощью C# это можно. Наверняка и через F# тоже.
А мало ли что за COM-объект, работа с таким может, и для админской задачи требоваться.

0

Curry,
Не в этом дело.

В папке Sample ровно одна задача. Нормальный программист от нормального языка ожидает, что строка 3 выведет то же самое, что и строка 1.

На практике:
Строка 1 выводит две строки текста.
Строка 3 выводит одну строку текста.
А если закомментировать строку 1, то строка 3 выводит тридцать строк текста. Тридцать!

Наверное, этому есть какое-то объяснение, но лично меня это бесит.

0

Про холивары вам виднее

Curry Священные войны 1885 постов

, летайте сами.

Моя реакция была на пассаж от Shamil, что REPL F# для задач администрирования удобнее, чем весь powershell.

И аргумент у него был такой же, да: 'я попробовал что-то, у меня не получилось.'

Добавлено через 10 минут

Сообщение от Curry Насчёт PS, то я некогда пытался поработать через него с СОМ-объектом.

Не могу ничего сказать по поводу регистрации на события от COM обьектов, но искал бы я решение
точно не на данном сайте; SO никто не отменял.

0

Сообщение от volodin661 И аргумент у него был такой же, да: 'я попробовал что-то, у меня не получилось.'

Не обманывайте. Аргументы я писал.

0

Резюмирую вышесказанное мной:

Когда транслятор выполняет неявные операции, это упрощает задачу, если писать в стиле "напишу, не думая, а транслятор пусть сам решает, что я имел ввиду". Но иногда приводит к неожиданным последствиям. Как, например, в случае знаменитых сишных "if(x=0)" или js-ных "map(parseInt)".

Из всех известных мне ЯП PowerShell - чемпион по количеству и сложности неявных операций. В первую очередь это касается преобразования типов и вывода в консоль.

Формат вывода зависит от контекста (предыдущего вывода). Почему Get-ScheduledTask выдаёт разный результат
Преобразование типов идёт по сложному алгоритму. Примерно так: https://devblogs.microsoft.com... ion-magic/

Проблема усугубляется тем, что эти алгоритмы толком не задокументированы. Кроме того, они зависят от внешних настроек (файлы форматов, зарегистрированные конвенторы) и, потенциально, ведут себя по-разному на разных компьютерах.


Наверное, неявные преобразования удобны, когда тебе нужно выполнять команды в консоли или написать простой скрипт. Проблемы возникают, когда тебе нужно написать сложный скрипт и/или скрипт для других администраторов (на стороне клиентов по всему миру) и/или скрипт, который не перестанет работать на новых версиях ОС (я и с таким сталкивался).


Поэтому лично мне F# более удобен. Но у F# есть два больших недостатка: 1) его мало кто понимает 2) нужно устанавливать дополнительно. Поэтому мне приходится писать на PowerShell (к счастью, редко).

0

Сообщение от Shamil1 Проблемы возникают, когда тебе нужно написать сложный скрипт

Когда нужно написать действительно сложный скрипт, то нужно использовать не скрипт, а компилируемый язык, со строгой статической типизацией, что бы компилятор нас мог проверить и отловить изрядно наших ошибок.
Иначе требуется много времени на отладку и тестирование.

0

Сообщение от Curry Когда нужно написать действительно сложный скрипт, то нужно использовать не скрипт, а компилируемый язык, со строгой статической типизацией

Я согласен. Но не всегда выбор языка зависит от меня. Некоторые клиенты не могут устанавливать на сервер никакие приложения, кроме явно указанных в белом списке. Политика их компании, часто связанная с требованиями местных законов.

0

0