Так. Работа с деревьями удобна в ФП. Конкурентность и параллельность — это тоже удобно в ФП. А для чего же тогда удобно ИП, кроме того, чтобы быструю сортировку написать?
Во первых, хаскель осмысленно стремится не жертвовать чистотой ради кратковременной выгоды, не более. Во вторых, во всём, что касается типов, хаскель нынче уже давно не на острие прогресса.
А решает, например, лёгкость освоения языка, ибо нужно много программистов, а где их взять?
Мне как программисту много программистов ни к чему. А возможность использовать удобный инструмент, чтобы не подгорать от использования неудобного инструмента, важна.
Ничего подобного. В ФП куда активнее используются абстракные интерфейсы, а паттерн-матчинг по заранее неизвестным типам невозможен за редкими исключениями (generics). Кроме того в ФП куда меньше распространён runtime reflection, который является верным путём к тому, чтобы сделать сложный, непонятный, магический, нечитаемый код.
Типы избавляют от необходимости писать 90% юнит-тестов. При этом влияние на качество кода они оказывают не ниже, а документация из типов намного лаконичнее и понятнее.
Нет. Если надо перед кем-то отчитаться о том, что сделали надёжно — используешь контракты. Если надо сделать надёжно — то используешь средства формальной верификации.
Если не угрозы катастрофы или гибели людей, то вам видимо и правда нужно доказательство корректности, а не для галочки. В таком случае стоит посмотреть в сторону более развитых систем типов и формальных методов доказательства корректности программ.
Для иммутабельного списка в хаскеле используется сортировка слиянием. В совокупности с ленивой моделью исполнения эта сортировка не даёт лишнего оверхеда по памяти и работает достаточно быстро.
Сортировка вектора же в хаскеле использует инкапсулированную мутабельность и так же не даёт дополнительного оверхеда по памяти.
HIE очень нестабилен, способен жрать очень много памяти, зато фичастый.
Ghcid наоборот же работает весьма стабильно и без особых проблем с производительностью, но фич у него минимум.
Ответьте тогда на вопрос, почему на сегодняшний день при всех своих очевидных преимуществах ФП-языки так не популярны?
Исторически так сложилось. Процитирую одного умного человека: "Одно из характерных качеств хаcкеля как языка и сообщества в том, что они вместе не стремились стать популярными, дав простой ответ на популярные вопросы.
Вместо этого выстраивали логичный principled путь решения реальных проблем, а не быстрого проникновения в сердце прохожего интересующегося."
Так вот, для того, чтобы выстроить логичный principled путь решения реальных проблем в PLT требовались многие годы, так же как и Haskell для того, чтобы стать production ready языком требовалось 15 лет. Это очень сильно отличает его от того же JS, который задизайнили за неделю, выпустили на свет как есть, а дальше строго берегли обратную совместимость. Но именно поэтому JS сейчас на коне, а Haskell есть там, где он есть. JS вышел на рынок и пусть крайне посредственно, но дал инструмент для решения задачи, которая без него никак до этого не решалась. Haskell стал production языком только через 15 лет после своего появления, когда все ниши уже заняты, а проблемы хоть и крайне отвратно и хрупко, но решены.
Ещё одной проблемой является то, что он другой. От программиста, который уже сносно программирует на языках надёжно занявших свои нишы, он требует учиться заного. Его предыдущий опыт ему тут не помогает, а даже наоборот мешает, от чего многие наверняка даже не освоив основы бросают язык, называют его сложным, перемудрёным и не нужным. Это наверное самая большая проблема, переучить кучу людей очень дорого, особенно когда они сами не хотят переучиваться.
Какой вы можете назвать общеизвестный проект, который написан на вашем любимом Хаскеле? У какого ФП-языка экосистема хотя бы приблизилась к объему C/C++/Java/JS?
Мы уже кажется выяснили, что ФП не популярен. Что вы этим хотели сказать совершенно непонятно.
Так. Работа с деревьями удобна в ФП. Конкурентность и параллельность — это тоже удобно в ФП. А для чего же тогда удобно ИП, кроме того, чтобы быструю сортировку написать?
Во первых, хаскель осмысленно стремится не жертвовать чистотой ради кратковременной выгоды, не более. Во вторых, во всём, что касается типов, хаскель нынче уже давно не на острие прогресса.
Мне как программисту много программистов ни к чему. А возможность использовать удобный инструмент, чтобы не подгорать от использования неудобного инструмента, важна.
Ничего подобного. В ФП куда активнее используются абстракные интерфейсы, а паттерн-матчинг по заранее неизвестным типам невозможен за редкими исключениями (generics). Кроме того в ФП куда меньше распространён runtime reflection, который является верным путём к тому, чтобы сделать сложный, непонятный, магический, нечитаемый код.
Ложь в каждом из пунктов.
Типы избавляют от необходимости писать 90% юнит-тестов. При этом влияние на качество кода они оказывают не ниже, а документация из типов намного лаконичнее и понятнее.
Может быть и не умею. А может быть просто знаю, как может быть. Но сейчас я ушёл в бэк на скале и теперь этот ужас меня уже не сильно волнует.
В реакте с композабельностью получше и rxjs не навязывают.
Ангуляр по популярности не превосходит Реакт, потому-что:
Ужас какой
del
Нет. Если надо перед кем-то отчитаться о том, что сделали надёжно — используешь контракты. Если надо сделать надёжно — то используешь средства формальной верификации.
Если не угрозы катастрофы или гибели людей, то вам видимо и правда нужно доказательство корректности, а не для галочки. В таком случае стоит посмотреть в сторону более развитых систем типов и формальных методов доказательства корректности программ.
Можно загнать текст в нестандартный буфер (
"ayyнапример) и вставлять от туда. Так заменяемый текст не будет затирать вставляемый.А при чём тут социалистическая революция, когда делать работников счастливее просто выгодно капиталисту?
Простите, но после вашего комментария на ум пришла вот эта паста:
Для иммутабельного списка в хаскеле используется сортировка слиянием. В совокупности с ленивой моделью исполнения эта сортировка не даёт лишнего оверхеда по памяти и работает достаточно быстро.
Сортировка вектора же в хаскеле использует инкапсулированную мутабельность и так же не даёт дополнительного оверхеда по памяти.
HIE очень нестабилен, способен жрать очень много памяти, зато фичастый.
Ghcid наоборот же работает весьма стабильно и без особых проблем с производительностью, но фич у него минимум.
Любая книга о Haskell
Исторически так сложилось. Процитирую одного умного человека: "Одно из характерных качеств хаcкеля как языка и сообщества в том, что они вместе не стремились стать популярными, дав простой ответ на популярные вопросы.
Вместо этого выстраивали логичный principled путь решения реальных проблем, а не быстрого проникновения в сердце прохожего интересующегося."
Так вот, для того, чтобы выстроить логичный principled путь решения реальных проблем в PLT требовались многие годы, так же как и Haskell для того, чтобы стать production ready языком требовалось 15 лет. Это очень сильно отличает его от того же JS, который задизайнили за неделю, выпустили на свет как есть, а дальше строго берегли обратную совместимость. Но именно поэтому JS сейчас на коне, а Haskell есть там, где он есть. JS вышел на рынок и пусть крайне посредственно, но дал инструмент для решения задачи, которая без него никак до этого не решалась. Haskell стал production языком только через 15 лет после своего появления, когда все ниши уже заняты, а проблемы хоть и крайне отвратно и хрупко, но решены.
Ещё одной проблемой является то, что он другой. От программиста, который уже сносно программирует на языках надёжно занявших свои нишы, он требует учиться заного. Его предыдущий опыт ему тут не помогает, а даже наоборот мешает, от чего многие наверняка даже не освоив основы бросают язык, называют его сложным, перемудрёным и не нужным. Это наверное самая большая проблема, переучить кучу людей очень дорого, особенно когда они сами не хотят переучиваться.
Мы уже кажется выяснили, что ФП не популярен. Что вы этим хотели сказать совершенно непонятно.