Комментарии 81
[sarcasm]
Хороший материал. Надо бы еще assembler с javascript сравнить…
[/sarcasm]
Хороший материал. Надо бы еще assembler с javascript сравнить…
[/sarcasm]
А может всё проще — хаскел переусложнён там, где мог бы быть простым?
В каком смысле переусложнён? Вы считаете, что всю ту же выразительную мощность можно было реализовать проще и понятнее?
В прямом — используются идиомы, которые чужды обычному человеку. А выразительную мощь можно натянуть на любые идиомы.
используются идиомы, которые чужды обычному человеку
Что значит «чужды обычному человеку»? И кто такой «обычный человек»? Сразу в голову приходит пример: числа. Ну, 2 яблока + 4 яблока — это понятно, а что такое 2 + 4 — нет. Ну т.е. вот какая-либо теория множеств или теория типов — они чужды обычному человеку?
А выразительную мощь можно натянуть на любые идиомы.
Что вы хотели этим сказать? Вы отрицаете различную выразительную мощность у разных языков программирования?
Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков. И таки считает он площадь сферы по формуле, а не выразительно мощно интегрирует её по поверхности. Не всем дано быть математиками, а написание прикладного по — задача скорее переводчика, чем математика.
Нет, я отрицаю причинно-следственную связь между ФП и выразительной мощностью. Это перпендикулярные вещи.
Нет, я отрицаю причинно-следственную связь между ФП и выразительной мощностью. Это перпендикулярные вещи.
не потеряло связь с реальным миром
В реальном мире нет чисел. И сфер нет. Вы считаете, что математика — плохой инструмент для моделирования реальности (похоже, я как-то задавал этот вопрос на Хабре, и мне кажется, что даже вам)?
Нет
Ну так вы считаете, что всю ту же выразительную мощность можно было реализовать проще и понятнее?
Я вам открою страшную тайну, но человек оперирует с числами через вполне себе конкретные аудио-визуальные образы. Числа — это как универсальная валюта, в которую можно конвертировать множество других предметов.
Через более понятные обычным людям идиомы — безусловно.
Через более понятные обычным людям идиомы — безусловно.
Э нет. Разные люди оперируют с числами (и вообще абстракциями) по-разному, далеко не всем для этого нужны аудиовизуальные образы.
Разные люди оперируют с числами (и вообще абстракциями) по-разному
И как ещё они оперируют, кроме аудиовизуальных образов?
Если при мысленном расчёте предела функции человек представляет запись этого предела, как на бумаге, то этот образ с реальным миром связан только тем, что похож на запись на бумаге. Аналогично различные диаграммы и прочее связаны с реальным миром только тем, что они похоже на какую-то визуальную картинку, но это не «конкретный образ». Вот я когда числа складываю, вижу их циферную запись, в чём тут конкретика? Это искусственная вещь.
В этом смысле всё связано с реальным миром, даже идиомы Haskell, достаточно представлять их код в голове.
В этом смысле всё связано с реальным миром, даже идиомы Haskell, достаточно представлять их код в голове.
На уровне понятий. Собственно, этим абстрактное мышление и отличается от предметного.
А «понятия», как, по-вашему, в мозгу представлены?
Нейрончиками и их связями, я подозреваю. Но вообще, конечно, это к психофизиологам.
Это не ответ на вопрос, но всё же.
Вот как представлено понятие «верх»? Тут можно вспомнить эксперименты про ношение очков, переворачивающих изображение. Со временем человек привыкает, и хоть картинка остаётся как бы перевёрнутой, для экспериментируемого она перестаёт быть перевёрнутой, потому что «верх» — это то, куда показывает поднятая рука. Т.е. «верх» у него становится визуально снизу, но для него это так же нормально, как для нас то, что «верх» — сверху. У него-то «верх» — тоже сверху :)
Вот как представлено понятие «верх»? Тут можно вспомнить эксперименты про ношение очков, переворачивающих изображение. Со временем человек привыкает, и хоть картинка остаётся как бы перевёрнутой, для экспериментируемого она перестаёт быть перевёрнутой, потому что «верх» — это то, куда показывает поднятая рука. Т.е. «верх» у него становится визуально снизу, но для него это так же нормально, как для нас то, что «верх» — сверху. У него-то «верх» — тоже сверху :)
Вы не ответили на вопрос о том, считаете ли математику не лучшим инструментом для моделирования реальности в той или иной области? Вот как по мне, так одна проблема, но существенная, сложность для человека, которую (проблему), на мой взгляд, лучше решать улучшением преподавания математики и упрощением (но не в ущерб строгости и выразительности) математики, а не заменой менее формальными инструментами.
Хорошо. Понятно, что пока мы не умеем строго считать выразительную мощность, мнения относительно оной могут сильно различаться, но тем не менее, есть пример простого аналога, к примеру, монад? Просто на мой взгляд, там и так уже проще некуда, что может быть проще трёх функций с определённым законами? Ну или взять линзы, там вообще просто обобщённая функция, а через одну неё и геттер и сеттер и много что ещё. Это опять же проще, чем какие-то навороченные объекты отдельно с геттерами и сеттерами (хотя вторые проще для понимания, но менее выразительны).
Вот только эта простота — не easy, а simple, поэтому порог входа высокий, но если понижать порог входа, то simpleness потеряется.
Через более понятные обычным людям идиомы — безусловно.
Хорошо. Понятно, что пока мы не умеем строго считать выразительную мощность, мнения относительно оной могут сильно различаться, но тем не менее, есть пример простого аналога, к примеру, монад? Просто на мой взгляд, там и так уже проще некуда, что может быть проще трёх функций с определённым законами? Ну или взять линзы, там вообще просто обобщённая функция, а через одну неё и геттер и сеттер и много что ещё. Это опять же проще, чем какие-то навороченные объекты отдельно с геттерами и сеттерами (хотя вторые проще для понимания, но менее выразительны).
Вот только эта простота — не easy, а simple, поэтому порог входа высокий, но если понижать порог входа, то simpleness потеряется.
Строгость и выразительность не является прерогативой исключительно функциональных языков.
Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет. Зачем они в императивном языке — ума не приложу :-)
Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет. Зачем они в императивном языке — ума не приложу :-)
Зачем они в императивном языке — ума не приложу
А вы думаете, что монады — это только IO? Например, монада Maybe сильно упрощает работу с null, монада Try — работу с ошибками (и да, я все еще говорю об императивных языках), да собственно даже удобная работа с коллекциями — это монада.
Зачем они в императивном языке — ума не приложу :-)
То-то их тянут в императивные языки. Что LINQ в C#, что for в Scala.
Монада — всего лишь абстракция связывания вычислений, способ переопределить «оператор ;», очень удобный синтаксический сахар.
> Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет.
Я, конечно, не уверен, но мне кажется что перед тем как высказывать экспертное мнение, стоит ознакамливаться с материалом. Тогда будет понятно зачем монады были введены, как используются и чем могут быть заменены и в каких языках.
Я, конечно, не уверен, но мне кажется что перед тем как высказывать экспертное мнение, стоит ознакамливаться с материалом. Тогда будет понятно зачем монады были введены, как используются и чем могут быть заменены и в каких языках.
Я там выше ответил про аудио-визуальные образы. Я числа представляю обычно в виде циферной их записи — это никак не идёт под раздел «конкретный аудио-визуальный образ», потому что с тем же успехом можно и монады представлять, в виде их записи в мат. нотации, ну или кода. Связи с реальностью будет не меньше.
Я числа представляю обычно в виде циферной их записи — это никак не идёт под раздел «конкретный аудио-визуальный образ»
В моем понимании, идет. Когда вы оперируете числами, у вас возбуждаются определенные группы нейронов в визуальной и слуховой коре — а это и есть «аудиовизуальные образы».
Прочтите комментарий исходный, с которого зашла речь про образы. Там про то, что вот де Haskell — далёк от человека. В моем, и, судя по всему, вашем понимании — теория категорий не дальше чисел, там диаграммы всякие, весьма наглядно. Но вряд ли это то, что имел в виду vintage
Т.е. ты, когда складываешь 2+2 или считаешь сдачу со ста рублей, вместо простого использования заученных с детства правил начинаешь представлять себе яблоки или какие другие «конкретные аудио-визуальные образы»?
И заодно: Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков.
Ну расскажи про состояние числа 2, какой у него класс и какие признаки. И насколько это знание в реальном мире поможет тебе посчитать сдачу в магазине.
И заодно: Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков.
Ну расскажи про состояние числа 2, какой у него класс и какие признаки. И насколько это знание в реальном мире поможет тебе посчитать сдачу в магазине.
Haskell очень прост и минималистичен. Просто непривычен для воспитанных на императивной парадигме и многословном синтаксисе.
Думаю, сложность вызывает функциональное программирование, а не сам язык. Сравнение Хаскеля (или другого функционального языка программирования) с любым другим императивным языком программирования даст похожий результат.
Программировать в функциональном стиле можно почти на любом ЯП.
если под функциональным стилем понимается использование map и reduce, и немножко замыканий, то конечно можно.
Ну лямбды, функции высшего порядка, чистые функции, каррирование, и т.д. — все это хоть в том же JS можно делать. Я уж не говорю про рекурсию.
наверное можно, но не придётся ли потратить те же четыре года, чтобы делать это правильно, особенно когда за тобой не приглядыват компилятор?
То, что эти идиомы впервые появились в функциональных языках и то по необходимости не делает ваш императивный код с использованием этих идиом функциональным ни в коей мере :-)
Суть не в словах, а в том, что за ними стоит. Функциональное программирование — это использование определенного подхода, а не языка при написании кода. Емнип, в том же Хаскеле можно и в императивном стиле писать (сам не видел, каюсь, но рассказывали коллеги).
К слову, лямбда-исчисление изначально не имело никакого отношения к ЯП (их тогда и не было).
К слову, лямбда-исчисление изначально не имело никакого отношения к ЯП (их тогда и не было).
ФП — это «программирование без изменения состояния», а не «программирование с использованием замыканий».
> «программирование с использованием замыканий»
А я где-то это утверждал?
А я где-то это утверждал?
Тут: http://habrahabr.ru/post/270707/#comment_8651791
И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.
И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.
> Тут: habrahabr.ru/post/270707/#comment_8651791
А процитируйте плз, где я сказал, что ФП — это «программирование с использованием замыканий».
> И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.
Странно, а определение чистой функции говорит нам следующее:
1. является детерминированной
2. не обладает побочными эффектами
А процитируйте плз, где я сказал, что ФП — это «программирование с использованием замыканий».
> И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.
Странно, а определение чистой функции говорит нам следующее:
1. является детерминированной
2. не обладает побочными эффектами
как бы:
является детерминированной = не зависит от внешнего состояния
не обладает побочнвми эффектами = не меняет состояние
является детерминированной = не зависит от внешнего состояния
не обладает побочнвми эффектами = не меняет состояние
Функция является детерминированной, если для одного и того же набора входных значений она возвращает одинаковый результат. Все.
Побочные эффекты — это модификация глобальных переменных, переданных параметров и т.п.
Вы таки думаете, что этого невозможно достичь хоть на том же питоне или js?
Побочные эффекты — это модификация глобальных переменных, переданных параметров и т.п.
Вы таки думаете, что этого невозможно достичь хоть на том же питоне или js?
Простой пример: function summ( a, b ){ return a + b }
Функция детерменированная? Вроде да. Давайте проверим:
var i = 0
var a = { valueOf(){ return i++ } }
console.log( summ( a, 1 ) ) // 1
console.log( summ( a, 1 ) ) // 2
Ой.
Функция детерменированная? Вроде да. Давайте проверим:
var i = 0
var a = { valueOf(){ return i++ } }
console.log( summ( a, 1 ) ) // 1
console.log( summ( a, 1 ) ) // 2
Ой.
Нет, по описанию этой функции нельзя сказать, детерминированная ли она.
(Привет слабой типизации)
(Привет слабой типизации)
Недетерменированная функция — это функция, про которую нельзя сказать, что она детерменирована, а не та, которая на каждый вызов возвращает разные значения.
Стойте, но мы же передаем разные входные значения (пусть и опосредованно, через переменную).
Нет, передаётся один и тот же объект «a» и константа «1».
А то, что результат выполнения опосредованно зависит от глобального состояния — в этом и есть суть недетерминированности.
А то, что результат выполнения опосредованно зависит от глобального состояния — в этом и есть суть недетерминированности.
Я даже не думал, что кто-то додумается переводить этот горе-вброс. Пщ против хачкеля, lmao.
Ваня, никогда не разочаровываешь.
Ваня, никогда не разочаровываешь.
я честно не понимаю сути такого сравнения языков, а тем более приведения в качестве какого-либо аргумента успешные проекты.
Причем на доводы о том, что в языке чего-то не хватает, или что какие-то вещи реализованы неверно, приводятся агрументы, вида
«а мне/успешному проекту, оно не нужно» или «а зато у нас докер». Как будто, что-либо мешает писать на языке успешные продукты,
ну плохой язык, ну и что, вещи практически независимые, в итоге максимальной популярностью обычно начинает пользоваться самый плохой инструмент из достаточных для решения задачи. А успешность написания программ зависит от качества программистов и менеджеров. Особенно аргумент про продукты тоже интересен, я подозреваю, что в NY больше го программистов, чем программистов на Haskell, пишущих публичные продукты, так что результат не сильно удивителен.
Причем на доводы о том, что в языке чего-то не хватает, или что какие-то вещи реализованы неверно, приводятся агрументы, вида
«а мне/успешному проекту, оно не нужно» или «а зато у нас докер». Как будто, что-либо мешает писать на языке успешные продукты,
ну плохой язык, ну и что, вещи практически независимые, в итоге максимальной популярностью обычно начинает пользоваться самый плохой инструмент из достаточных для решения задачи. А успешность написания программ зависит от качества программистов и менеджеров. Особенно аргумент про продукты тоже интересен, я подозреваю, что в NY больше го программистов, чем программистов на Haskell, пишущих публичные продукты, так что результат не сильно удивителен.
А я иначе эту статью вижу. Она про конфликт между понятиями «хороший»/«плохой» между теоретиками и практиками. Когда ты один, ради интереса учишь языки, пытаешься на них что-нибудь «выражать» на синтетических или не очень примерах — у тебя одни представления о том, что будет хорошо, а что нет. Когда же ты попадаешь в «реальный мир» — работаешь с массой других людей, разных компаний, большим количеством чужого кода — начинаешь совсем иначе относиться. И в этой статье как раз хорошо проиллюстрирован вот этот сдвиг (хоть и не окончательный) приоритетов с «теоретика» на «практика» — автор только коммуницируя с другими начал понимать, что возможно, то что ему кажется «объективно хорошим» — не совсем то, что нужно в реальном мире.
мне определенно не нравится деление на «теоретиков» и «практиков», это похоже на попытку спрятатья за какую-то ширмочку. Но в целом в «реальном мире» указанные «теоритические» технологии вполне себе успешно используются. Ну и ещё раз скажу, чуть другими словами, хорошесть/плохость языка и применимость или уместность его для конкретного проекта выполняемого конкретной комадной это разные категории.
Об этом и речь — шкала должна быть в практической уместности и применимости реальными командами на реальных проектах. Go вызывает столько эмоций и его так расхваливают, потому что он даёт возможность быстро и качественно сделать работу при меньших затратах практически в любой команде. Поэтому когда начинают разглагольствовать о теоретических обоснованиях, почему Go плох — это другая категория, другой взгляд вообще на вещи.
Я нередко слышу от гоферов, что они выбрали Go просто потому что быстро позволил писать крутой софт. Если завтра появится ещё более удачное решение, которое будет более практично и будет позволять более быстрее делать такой же качественный результат — не моргнув глазом, перейдут с Го на него. Я и сам абсолютно такого же мнения. И это то, что я называю «практиками».
А «теоретики» (в моей терминологии) — строят какую-то искусственную систему координат, в которую вписывают инструменты, и судят с пеной у рта о языках по ней, часто на много-много лет закрывая себя только в рамках одного языка.
Хотя, возможно, моя терминология не сильно удачная, и можно лучше придумать. Но, я надеюсь, понятно, что в этой модели нет никаких проблем, что языки вроде Хаскеля реально используются в реальных проектах — если это практично (например, команда знает очень хорошо только хаскель — почему нет?), то это хороший выбор.
Я нередко слышу от гоферов, что они выбрали Go просто потому что быстро позволил писать крутой софт. Если завтра появится ещё более удачное решение, которое будет более практично и будет позволять более быстрее делать такой же качественный результат — не моргнув глазом, перейдут с Го на него. Я и сам абсолютно такого же мнения. И это то, что я называю «практиками».
А «теоретики» (в моей терминологии) — строят какую-то искусственную систему координат, в которую вписывают инструменты, и судят с пеной у рта о языках по ней, часто на много-много лет закрывая себя только в рамках одного языка.
Хотя, возможно, моя терминология не сильно удачная, и можно лучше придумать. Но, я надеюсь, понятно, что в этой модели нет никаких проблем, что языки вроде Хаскеля реально используются в реальных проектах — если это практично (например, команда знает очень хорошо только хаскель — почему нет?), то это хороший выбор.
В целом согласен.
Кстати, я слышу от хаскелистов то, что они выбирают Haskell, т.к. он дает им возможность качествено и быстро писать софт и легко его поддерживать, при этом у большинства их них в бекграунде есть пачка императивных языков, включая Go. Я правда с Go не знаком настолько, чтобы обсуждать его в данном контексте (практики написания крутых программ). Произошло это т.к. причин продолжать его изучение дальше, чем базовые tutorial-ы, я не увидел. Но даже на этом уровне по сравнению с другими языками той же категории (на мой взгляд python и компания, он выглядит вполне пристойно). Т.е. если я, по какой-то причине, возьмусь писать крутой софт на Go, то я буду страдать от отсуствия возможностей, которые я хотел бы видеть, в языке и с которыми привык работать (те самые теоритические обоснования). В тоже время, замечу, есть достаточно мало областей, где эти причины стали бы для непреодолимой проблемой. как-то так…
Кстати, я слышу от хаскелистов то, что они выбирают Haskell, т.к. он дает им возможность качествено и быстро писать софт и легко его поддерживать, при этом у большинства их них в бекграунде есть пачка императивных языков, включая Go. Я правда с Go не знаком настолько, чтобы обсуждать его в данном контексте (практики написания крутых программ). Произошло это т.к. причин продолжать его изучение дальше, чем базовые tutorial-ы, я не увидел. Но даже на этом уровне по сравнению с другими языками той же категории (на мой взгляд python и компания, он выглядит вполне пристойно). Т.е. если я, по какой-то причине, возьмусь писать крутой софт на Go, то я буду страдать от отсуствия возможностей, которые я хотел бы видеть, в языке и с которыми привык работать (те самые теоритические обоснования). В тоже время, замечу, есть достаточно мало областей, где эти причины стали бы для непреодолимой проблемой. как-то так…
НЛО прилетело и опубликовало эту надпись здесь
Вы сознательно пропустили часть процитировнной Вами фразы? Бреинфак, не является разумным образом, достаточным для написания веб фреймворка. PHP, например, является, и несмотря на все проблемы языка, особенно в версиях 4.x мы можем видеть множество решений на нём.
Соглашусь, что из моей фразы совершенно непонятно почему иногда наблюдаются мирграции на язык с меньшими проблемами, но это нужно гораздо точнее формулировать фразу или сильно расписывать, а мне лень.
Соглашусь, что из моей фразы совершенно непонятно почему иногда наблюдаются мирграции на язык с меньшими проблемами, но это нужно гораздо точнее формулировать фразу или сильно расписывать, а мне лень.
НЛО прилетело и опубликовало эту надпись здесь
версия PHP 4 тут при том, что является примером моему утверждению, а brainfuck нет. Пример был необходим, чтобы больше не возникало идей для передергиваний.
Создателями обычно двигает знание языка, знание похожих языков, наличие готовых библиотек, наличие знаний у команды. Возможно то, что вы называете «субьективной легкостью вхождения». Наприме, если у вас тут есть команда людей на OCaml, а вам нужно написать сложный проект, с большим количеством шаблонного кода, то вы возьмете MetaML, а не go, python или что-либо ещё, на что команда явно потратит больше времени на изучение.
Ещё раз повторюсь, язык не должен быть хорошим, для того чтобы на нём можно было успешно писать, он должен быть достаточным, чтобы на нём ваша команда могла решать поставленные перед вами задачи, а его экосистема должна иметь нужные вам средства для работы (библиотеки/утилиты/документацию/статьи). В го нету очень многого, с точки зрения CS это огромный шаг назад в развитии, никакого анализа решений на рынке, результатов в науке — это плохо? Ну с точки зрения программиста, наверное да, но только когда эти возможности ему нужны. Т.е. в обем-то ответ на половину упрёков (разумных естественно), может быть «да, плохо, решается так (ссылка), ну и что дальше?».
Например, тот же haskell тоже далеко не идеален, метапрограммитование только generic-s (не путать с явовыми) и ужасный TempateHaskell, kinds equal types нету, т.е. никаких там зависимых типов (кроме костылей с синглетонами), function patterns — нет не завезли, и это если не углубляться, причем в разных языках рядом все это есть, но для решения повседневных задач это не нужно.
Создателями обычно двигает знание языка, знание похожих языков, наличие готовых библиотек, наличие знаний у команды. Возможно то, что вы называете «субьективной легкостью вхождения». Наприме, если у вас тут есть команда людей на OCaml, а вам нужно написать сложный проект, с большим количеством шаблонного кода, то вы возьмете MetaML, а не go, python или что-либо ещё, на что команда явно потратит больше времени на изучение.
Ещё раз повторюсь, язык не должен быть хорошим, для того чтобы на нём можно было успешно писать, он должен быть достаточным, чтобы на нём ваша команда могла решать поставленные перед вами задачи, а его экосистема должна иметь нужные вам средства для работы (библиотеки/утилиты/документацию/статьи). В го нету очень многого, с точки зрения CS это огромный шаг назад в развитии, никакого анализа решений на рынке, результатов в науке — это плохо? Ну с точки зрения программиста, наверное да, но только когда эти возможности ему нужны. Т.е. в обем-то ответ на половину упрёков (разумных естественно), может быть «да, плохо, решается так (ссылка), ну и что дальше?».
Например, тот же haskell тоже далеко не идеален, метапрограммитование только generic-s (не путать с явовыми) и ужасный TempateHaskell, kinds equal types нету, т.е. никаких там зависимых типов (кроме костылей с синглетонами), function patterns — нет не завезли, и это если не углубляться, причем в разных языках рядом все это есть, но для решения повседневных задач это не нужно.
Я что-то вот не понимаю, уже не первая (и явно не последняя) статья о сравнении языков, о том кто лучше, кто хуже, у кого какие проблемы и т.д.
А вот почему микроскоп лучше молотка? и тем и другим можно забивать гвозди, если того требует ситуация и задача. Но это далеко не значит, что молотком можно изучать микроорганизмы.
Проблемы есть у всех яп. Нет и не будет идеального языка программирования, просто потому что «человеки» никогда не придут к единому мнению, всегда кто-то будет против чего-то. И поэтому выбирать язык для создания того или иного проекта наверное имеет смысл не по тому на сколько «острое у него лезвие топора», а на сколько дешево\быстро\качественно\расширяемо\затратно создать прототип и выкинуть на рынок.
Вот php — плохой язык, так все говорят повально. Он создан умирать, — говорят в каждом подобном топике. Тем не менее на нем сделано уйма полезных и хороших продуктов. C# тоже многим не нравится, Python также находит своих недоброжелателей, но как-то это не меняет предыдущего высказывания.
Так может уже перестать сравнивать теплое с мягким или жидкое с соленым? Я бы вот с радостью узнал в каких областях тот или иной язык лучше применять и почему. Да, знать минусы надо и хорошо, что о них рассказывается. Но полемика ради полемики же во всем остальном, разве нет?
А вот почему микроскоп лучше молотка? и тем и другим можно забивать гвозди, если того требует ситуация и задача. Но это далеко не значит, что молотком можно изучать микроорганизмы.
Проблемы есть у всех яп. Нет и не будет идеального языка программирования, просто потому что «человеки» никогда не придут к единому мнению, всегда кто-то будет против чего-то. И поэтому выбирать язык для создания того или иного проекта наверное имеет смысл не по тому на сколько «острое у него лезвие топора», а на сколько дешево\быстро\качественно\расширяемо\затратно создать прототип и выкинуть на рынок.
Вот php — плохой язык, так все говорят повально. Он создан умирать, — говорят в каждом подобном топике. Тем не менее на нем сделано уйма полезных и хороших продуктов. C# тоже многим не нравится, Python также находит своих недоброжелателей, но как-то это не меняет предыдущего высказывания.
Так может уже перестать сравнивать теплое с мягким или жидкое с соленым? Я бы вот с радостью узнал в каких областях тот или иной язык лучше применять и почему. Да, знать минусы надо и хорошо, что о них рассказывается. Но полемика ради полемики же во всем остальном, разве нет?
Он создан умирать, — говорят в каждом подобном топике
Эта фраза не означает, что язык должен умереть и исчезнуть.
Это сказано в том смысле, что на PHP не стоит делать программы, крутящиеся в вечном цикле. Он рассчитан на инициализацию, обработку запроса, завершение.
Ну вообще-то в статье четко сказано, что на haskell вы будете гораздо продуктивнее, а начит быстрее выбросите прототип на рынок и приводятся аргументы в виде недостатков go. Области применения у языков общего назначения (в отличии от php) тоже одинаковые, это сравнение одного универсального молотка с другим.
Что-то мне не кажется, что 4 года потраченного на изучения haskell будут продуктивнее быстрого старта с go. В общем-то я ничего не имею против, но было бы круто увидеть четкое высказыванием например — «изучите {lang} потратив на него N часов и вы получите следующие преимущества, в отличии от [...] потому как имеются такие-то и такие-то преимущества и минусы.» И вот на мой взгляд это куда объективнее при сравнении двух молотков, а статья, лично у меня, вызывает скорее ощущение сравнение микроскопа с молотком. Хотя я могу глубоко заблуждаться и возможно совершенно не понял посыл в статье.
на хаскеле было бы продуктивнее, если бы все писали на хаскеле.
всетаки большая часть по это скомбинированные примитивы.
классическая проблема курицы или яйца, помноженная на высокий порог входа.
всетаки большая часть по это скомбинированные примитивы.
классическая проблема курицы или яйца, помноженная на высокий порог входа.
И при всём этом, Go оказывается гораздо более популярным, чем Хаскель, если верить GitHub. Внезапно, на Go уже написано так много потрясающих проектов, вроде Docker, InfluxDB, etcd, consul, prometheus, packer и многих других.У го есть проблемы, но он создан что-бы разрабатывать продукты (своей нишы), а для чего создан хаскель?
Haskell создан для того, чтобы был основной язык для изучения свойств ленивых функциональных языков. В то время на этой нише не было ни одного подобного языка, а запрос был, впрочем за последние 20 лет ситуация не изменилась.
То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность. И за последние годы Haskell экосистема заметно продвинулась в данном направлении.
То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность. И за последние годы Haskell экосистема заметно продвинулась в данном направлении.
То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность.
Это реально так или просто излишнее утрирование?
Скорее реально, лучше распишу полностью, чтобы не было недоговоренного, или если что меня бы поправили. Изначально Haskell академический язык и песочница для различных исследований и проверки концепций, до ~95 года (т.е. около 5 лет существования языка) в нём нельзя было делать полноценного IO и программа это была или подача строки на вход и оно выдавала строку на вывод, или чуть-чуть расширенный набор примитивов. Называть такой язык не исследовательским языком тяжело и языком на котором можно писать программы тяжело. Однако среди авторов языка и тех кто с ним работал были и люди, которые двигали его в сторону, где его использование в общем случае было бы возможно. В районе ghc-6.12 уже стало достаточно пристойно, хотя и все равно было много вопросов. В общем-то языком, на котором можно писать полезные программы он стал не так и давно, и в планах изначально этого не было, просто так получилось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбор языка (Haskell vs Go)