Дякую!

Так як сайт університету Wisconsin—Milwaukee періодично змінює розташування документу, то замінив в дописі посиланням на копію, зебережену в Wayback Machine.

Какие у вас впечатления от OCaml по сравнению с производными от Algol?

Другой момент, что вы пытались продемонстрировать гифкой, что нельзя продемонстрировать текстом?

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

достаточно показать, что компилируется какой-то hello world.

Да, пример кода в любом случае надо было брать покороче.

Спасибо!

Да, гифка получилась слишком долгой. Записывать полноценное видео с таким же содержанием — вроде бы и перебор? Может быть, оптимальный вариант — разделить гиф на два отдельных. Тогда первый будет показывать окно редактора с кодом. А второй — выполнение команд в консоли. По отдельности они будут достаточно короткими, чтобы не вызывать желание перемотать.

предпочитаю сам разобраться, а не подглядывать у кого-то

Мне кажется, для этого очень хорошо подойдёт книжка [Crafting Interpreters](craftinginterpreters.com/contents.html). Я и раньше думал, что автор хорошо объясняет: кратко, но не упуская важных деталей, доходчиво и точно. А когда сам попытался письменно сформулировать свои мысли для этой статьи, прочувствовал с новой силой, насколько талантливо пишет Нистром.

И не знаю считается ли это подглядыванием :) Но если знакомы с C#, в репозитории проекта [Minsk](github.com/terrajobst/minsk) код написан очень неплохо. Чисто, хорошо структурирован — в общем, приятно читается. При этом объём кода достаточно небольшой. Проект хорошо подходит для того, чтобы в нём разобраться за разумный срок без подсказок.

Добавлю с удовольствием. Отправил запрос.

Спасибо! :)

Спасибо!

Спасибо!

Технически проект можно было реализовать практически на любом языке. Поэтому критерии выбора F# — субъективные. Которые в общем сводятся к: надо, чтобы мне было интересно. Разумеется, если бы речь шла о коммерческой командной разработке, приоритеты были бы другие.

Если оставить за скобками функциональный подход, чем ещё оправдан выбор F#?

Во-первых, хотелось попробовать что-то новое и отличающееся от C# и вообще семейства языков с фигурными скобками. C# — по-моему, вполне приятный язык. Просто мне хватает «общения» с ним в рабочее время. При этом F# работает на .NET. А это значит, что не пришлось выделять время на изучение нового менеджера пакетов и системы управления билдами.

Во-вторых, в F# реализовано много современных языковых фишек. Многие из них появились в C# совсем недавно. Например, nullable reference types добавили в C# 8.0, релиз состоялся в сентябре 2019. В частности, при работе с F# можно «пощупать»:

• [По умолчанию null не входит в множество значений типа, объявленного в F#-коде](docs.microsoft.com/...​erence/values/null-values). Вы, скорее всего, знакомы с идеей Null safety. Если нет, можно почитать хорошее и краткое объяснение вот [здесь](softwareengineering.stackexchange.com/a/413150/134523).
• В языке есть так называемые [Discriminated Unions](docs.microsoft.com/...​ence/discriminated-unions). Наверное, самый знаменитый пример такого типа — Option или Maybe. Не смог найти краткого описания. Если Вам интересны подробности, дайте знать.
• Pattern matching. Мне кажется, именно в сочетании с Discriminated Unions можно оцень насколько мощным инструментом может быть сопоставление с образцом.
• Прочие вещи типа [Object expressions](docs.microsoft.com/...​erence/object-expressions), [Primary constructors](docs.microsoft.com/...​ence/members/constructors) и т.п.

В-третьих, от некоторых свойств, характерных для функциональных языков, можно не отказываться и в ОО коде на F#, а от некторых — отказаться в принципе невозможно. И необходимость под них подстраиваться расширяет кругозор и помогает держать мозг в тонусе. Что-то сродни тому, когда рекомендуют почистить зубы левой рукой, стоя на одной ноге :)

• В F# реализован [глобальный вывод типов](stackoverflow.com/a/399392/818321). Это значит, что на F# можно писать программы без единой аннотации типов. Синтаксис получится такой же чистый и краткий, как например у программы на Python или Ruby. Но при этом компилятор отловит ошибки несоответствия типов на этапе трансляции, а не во время исполнения. Я не уверен, что отсутствие аннотаций типов — это хорошая идея в случае командной разработки. Но поработать с языком с глобальным выводом типов — как минимум интересный опыт.
• F# — это [expression-oriented язык](stackoverflow.com/a/5068577/818321). В результате в F# нет инструкций return, break, continue. Насколько сильно нужно перестроить мышление, чтобы писать код без них, можно прочувствовать только попробовав.
• В F# по умолчанию все значения доступны только на чтение. Это очень удобно. Почему? Если я собираюсь какое-то значение модифицировать, я должен его явно пометить как mutable. В итоге только взглянув на объявление значений, не просматривая весь код, уже можно понять будут ли они изменяться где-либо или останутся константными. Легкость получения информации о коде — это хорошо.

Мне кажется, проект было бы приятно писать и на TypeScript. С одной стороны, в TS есть return, break, continue и все остальные вещи привычные нам по языкам типа C#, Python или Ruby. С другой, в TS есть и Null safety и Discriminated Unions и, хоть и не такой мощный как в F#, но удобный вывод типов. Плюс некоторые возможности, которых нет ни в C#, ни F#, например тот же [Control flow based type analysis](mariusschulz.com/...​pe-analysis-in-typescript).