F# как первый язык программирования — Боль?

Question

[NeoAnderson]

Реально ли начать программировать сразу на F# вооружившись дискретной математикой и Computer Science или надо чтото ещё...

- Какие минусы?
- Какие плюсы?

Comments

[Александр Нестеров]

Для начала вооружитесь правилами. Конкретно п.5.15. Там довольно подробно описано отношение модерации к подобного рода вопросам.

[Василий Дёмин]

На F# не писал, но для того же хаскеля этих знаний достаточно

[NeoAnderson]

Василий Дёмин, не будет ли это ошибкой, и стоит ли вначале всё же пописать чтото на Си, и т.п. просто глядя на код написанный на F# он както сразу понимается, такое же ощущение как от PHP

[Василий Банников]

Минусов каких-то глобальных не вижу. Он просто другой и изучать его надо иначе, чем какой-нибудь си

[Василий Дёмин]

NeoAnderson, Я не думаю, что выбирать первым функциональный язык - это плохо. Но опыта в этом вопросе у меня нет, я сам с бейсика начинал

Answer 1

[Dmitry Roo]

Вот такой минус есть: 8 вакансий «F#»

Comments

[NeoAnderson]

Для Pet

Answer 2

[Александр Скуснов]

Тебя поддерживают как минимум двое: Дмитрий Сошников и Сергей Абрамов (лекции по Haskell (а это тоже ФП) на Интуите)

Answer 3

[Griboks]

Реально. Можно начинать программировать сразу на любом языке. Имея базу, языки меняются как перчатки.

- Какие плюсы?

- Вы научитесь программировать хоть на чём то.
- Вы будете истинно верным математически правильным формально доказуемым программистом.

- Какие минусы?

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

Comments

[NegroAzul]

Это ООП - устаревшая концепция. А ФП более эволюционно продвинутое.

[Griboks]

NegroAzul, ходят слухи, что функциональное программирование появилось задолго до ооп, поэтому не могло эволюционировать от него.

[NegroAzul]

Griboks, А я где-то утверждал, что ФП эволюционировало от ООП?

[NegroAzul]

Griboks, я написал, что

ООП - устаревшая концепция. А ФП более эволюционно продвинутое.

Продвинутое, а не эволюционирует от ООП. Это отдельная ветвь эволюции, как птицы и киты, например. Понимаете?

[Василий Банников]

- Никому не нужно функциональное программирование - это устаревшая концепция, которая давно была вытеснена более эволюционно продвинутым ООП.

Смелое заявление на фоне того как все новые языки, кроме совсем уж ущёрбных, тащат из ФП кучу всего:
1. Алгебраические типы данных
2. Функции первого порядка - они тупо везде
3. Отказ от Null. (где-то сразу, а где-то сбоку прикручивают)
4. Простые типы без методов (record из C# тот же)
5. Неизменяемость по-умолчанию (на примере let из rust или того что в Kotlin не стали делать final var или что-то подобное, а завели более короткое ключевое слово)

Я бы сказал, что ФП - это не "эволюционно продвинутая", а сильно опередившая своё время концепция.

[Griboks]

Василий Банников, большая куча - это, конечно, хорошо, но бесполезно без термоядерной базы ооп.

Не стоит забывать, что вывести на экран hello wolrd - уже непосильная для ФП задача.

[Василий Банников]

Griboks, это ещё почему?

[Griboks]

Василий Банников, потому что i/o - это нарушение основополагающих принципов фп.

[Василий Банников]

Griboks, io по умному называется побочным эффектом.
Можете дать ссылку, где сказано, что в программе не должно быть побочных эффектов?

[Griboks]

Василий Банников, ну разумеется, вот целая статья.

Там много всего написано, может даже неправда, но ключевые моменты даны. Например:

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

Или вот ещё один:

Для преодоления недостатков функциональных программ уже первые языки функционального программирования включали не только чисто функциональные средства, но и механизмы императивного программирования (присваивание, цикл, «неявный PROGN» были уже в Лиспе).

Забавно, да? Уже первые языки фп не смогли работать без костылей со стороны ооп.

В любом случае для i/o нужно контролировать состояние буфера, что принципиально невозможно в фп. С другой стороны буферы и ооп в целом естественно вытекают из физического устройства компьютеров.

[Василий Банников]

Griboks,

Уже первые языки фп не смогли работать без костылей со стороны ооп.

Но речь же тут идёт про элементы императивщины, а не про ООП.

[Griboks]

Василий Банников, проблема в том, что концепция фп несостоятельна сама по себе. Безусловно, в ней присутствуют интересные идеи, которые можно было бы добавить в ооп языки, но не более того.

Answer 4

[NegroAzul]

Категорически не согласен с Griboks
> Какие плюсы?
Их масса.
Функциональные языки куда лучше работают с состоянием, концепции и абстракции ФП позволяют лучше работать со сложностью программных систем.
По работе, ее дофига, смотрите на https://functional.works-hub.com/functional-progra...
Из языков больше будет востребован haskell, нежели F#.
> Какие минусы
Возможно более высокая кривая обучения, но это точно лучший путь.
ООП не то чтобы изжил себя, скорее всего, не поспевает за изменениями и в функциональных языках уже куда больше крутых инструментов для работы с кодом, нежели в чисто ООП языках.
Многое из ФП медленно перетекает в ООП языки - лямбды, анонимные функции, иммутабельность, плюсовая библиотека Ranges - чисто эмуляция композиции функций, которая во всех ФП языках работает просто из коробки.
Простыми словами, на том же Хаскелле можно в N/2 поместить то же, что на условной джаве займет N^2 строчек кода, да еще и читабельность будет выше и смысл транслироваться будет куда лучше.

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

Comments

[Griboks]

Функциональные языки куда лучше работают с mutable state, концепции и абстракции ФП позволяют лучше работать со сложностью программных систем.

На самом деле ооп специально придумали, чтобы лучше работать с mutable state)

По работе, ее дофига

Мне выдало 49 вакансий, а по ооп - 3000.

но это точно лучший путь

Каждый раз в этот момент я вспоминаю, что 100500 точно лучших функций разложены по файлам и папка, что и является ооп на минималка.

Многое из ФП медленно перетекает в ООП языки

Получается, фп - это часть ооп, которая уже встроена. Ну и зачем учить лишний функциональный язык?

да еще и читабельность будет выше и смысл транслироваться будет куда лучше.

С другой стороны, 100 строчек фп можно записать 10 строчками ооп при грамотном переиспользовании кода. А еще окружающий мир - это объекты, и наш мозг работает с объектами. И даже если выучит фп, то невозможно написать чистый код из чистых функций, потому что пользователь взаимодействует через объекты - их придется использовать в любом случае.

[NegroAzul]

Griboks,

И даже если выучит фп, то невозможно написать чистый код из чистых функций,

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

потому что пользователь взаимодействует через объекты - их придется использовать в любом случае.

Спорно. Что значит " пользователь взаимодействует через объекты"?

Каждый раз в этот момент я вспоминаю, что 100500 точно лучших функций разложены по файлам и папка, что и является ооп на минималка.

Не понял абзац.

На самом деле ооп специально придумали, чтобы лучше работать с mutable state)

Да, вы правы, в ООП-языках проще работать с изменяемым состоянием. Что не значит, что это лучший подход.

Мне выдало 49 вакансий, а по ооп - 3000.

Где выдало? И что это за вакансии?

Получается, фп - это часть ооп, которая уже встроена. Ну и зачем учить лишний функциональный язык?

Нет, ФП не часть ООП. Скорее, правильнее будет сказать, что многие современные языки - мультипарадигменные. Но не все! Но учить, как мне кажется, лишним не будет.

[Griboks]

NegroAzul,

Что значит " пользователь взаимодействует через объекты"?

В реальном мире нет генераторов и итераторов. Зато есть прерывания и буфер видеокарты, которые по своей сути являются объектами. И все обертки, библиотеки и системные sdk предоставляют объектный интерфейс. Хотя, никто не запрещает конвертировать в самом языке, но зачем?

Не понял абзац.

Вы не можете просто написать в одном файле 5000 чистых функций. Все равно нужна какая-то группировка, только вокруг функциональности вместо данных. Получается, тоже самое ооп, только через заднее место. А если еще генерики отделить, то вообще вылетое ооп.

[NegroAzul]

ато есть прерывания и буфер видеокарты, которые по своей сути являются объектами.

Прерывание - это объект? Вы уверены? Мне кажется, куда более подходящая аналогия в данном контексте - это "сигнал". Вам не кажется, что у вас в руках молоток, и все что вы вокруг теперь видите - это гвоздь?

И все обертки, библиотеки и системные sdk предоставляют объектный интерфейс.

Нет, системные СДК часто написаны с самым простым Си-интерфейсом, без ООП. Что не значит, что нельзя и не стоит использовать абстракции более высокого уровня.

Вы не можете просто написать в одном файле 5000 чистых функций. Все равно нужна какая-то группировка, только вокруг функциональности вместо данных. Получается, тоже самое ооп, только через заднее место. А если еще генерики отделить, то вообще вылетое ооп.

Ну так напишите в разных файлах? В Хаскеле есть неймспейсы, модули, способов организации кода более чем достаточно. (https://livebook.manning.com/book/get-programming-...) Вам не кажется, что файл - это в принципе довольно низкоуровневая абстракция в контексте программирования, и не очень хорошо служит в качестве единицы деления функциональности?