Быдлоязык — язык, на котором пишет много быдлопрограммистов в процентном соотношении.
Быдлопрограммистам писать проще на языках с низким порогом вхождения, так как высокий порог вхождения они осилить почти не в состоянии.
Когнитивный диссонанс возникает от того, что люди сначала думают, что «быдлоязык = плохой язык», а потом упорно это пытаются опровергнуть фразами типа «не язык плохой, а программисты на нём плохие», как будто сам язык абсолютно никак не связан с программистами, на нём пишущими.
GHC с параметром --interactive — интерпретатор.
runghc — программа, выполняющая исходник без компиляции (т.е. в отличие от интерпретатора, не интерактивная сессия, а просто runghc some.hs), в данном случае как раз, по-моему.
Я как-то сделал замечание в форуме по Nemerle, что неплохо бы генерировать свёртки и развёртки автоматически, благо не такая сложная задача. В ответ услышал, мол, в каком же порядке обходить дерево, например?
В Haskell благодаря чистоте это не имеет значения, а благодаря монадам я всегда могу указать «направление».
Например, распечатка списка в прямом порядке: foldr ((>>).print) (return ()) [1,2,3],
а вот в обратном: foldr ((flip (>>)).print) (return ()) [1,2,3]
В остальных языках монады тоже есть, но они вшиты в язык, потому не видны, но и управлять ими возможности нет.
Чтобы иметь возможность обитать на 10-м этаже, иногда приходится спускаться на 2-й сложным способом. Другие предпочитают подниматься не выше 5-го.
Компилятор указывает вам места, которые работать не будут, так как тип не совпадает. Конечно, это место может быть важным, но оно всё равно не заработает. Я пишу undefined и заключаю в комментарий весь код. Так что слово «вспомогательный» там было просто процитировано, это не суть. undefined имеет любой тип, я могу его поставить на место некоторой «преобразовательной» функции, которой пока что не написал. В общем, ей можно заткнуть вообще любое место, так что тут проблемы на самом деле нет.
> Глобальные переменные и побочные эффекты — не единственные проблемы в программировании
Дык! Поэтому хотят вообще возможность в типе функции указать, что она не просто осуществляет ввод-вывод, а ровно в тот Handle, который ей передали, а не куда-то ещё, но это пока слишком круто ;)
Программист может решать сам, мутабельные переменные есть, dynamic есть, template haskell есть. Другое дело, что выглядит это страшновато, но тут на самом деле вопрос баланса. Сделай удобным — начнут пользоваться, где попало, что плохо. А вот где эта золотая середина — сказать сложно.
Т.е. если очень нужно, оно есть, пусть решает программист, но сначала подумает, а дейсвительно ли нужно.
Тестировать надо не только для того, чтобы убедиться, что не ошибся сейчас. Вы не ответили на самое интересное с рефакторингом. Вместо получения 20 ошибок от компилятора, я буду отлавливать exception'ы и по очереди искать, где же я при изменении старого кода ошибся? Это не решение. Или, может, я и есть тот дурак, а умные и рефакторят без ошибок?
Тот, кто захочет заменить способ хранения графа, конечно, не дурак, но что же, все недураки перед рефакторингом сидят и помечают все места, где надо не забыть заменить код? А в старый код ещё и вникать придётся. Какая-то monkey-work, честное слово. Достаточно где-то не заменить функцию, и ловим ошибки во время работы программы. Я же иногда даже просто беру и меняю тип данных. Всё. Далее мне компилятор сам выдаст все места, где надо поправить (тут, кстати, играет роль не только система типов, но и различие написания конструкторов и переменных и прочее), а там я уже решаю, нужно тут вникать, или сделать тривиальное изменение.
Разные вспомогательные функции в Haskell'е легко и просто описываются такой замечательной штукой, как undefined. Если вы не случайно ошиблись, а именно что хотите временно отложить написание или исправление — undefined вам в руки, сам пользуюсь, так что это надуманная проблема.
Я не доверяю ни Васе Пупкину, ни Пете Васечкину, но в Haskell'е я по типу вижу (без всяких доверий), что функция не меняет глобальных переменных и не пишет в лог. А захоти я изменить тип графа, я его просто поменяю, а потом исправлю ошибки типизации. И с большой вероятностью, ничего не сломается. Тут мы и подходим к вопросу разработки больших систем, когда я предпочту не вникать в код, если этого можно избежать.
Дык на то оно и ощущение. Понятное дело, что ошибки могут быть, но то, что несколькодневный код работает сразу же, поражает. Уж который раз, а всё никак не привыкну.
Как это не факт? Всё, что придётся тестировать на Haskell, придётся тестировать и на Python'е. Плюс как минимум типы. Я тут на днях переворачивал вверх дном код, так повылазило очень много ошибок типизации (где-то недосмотрел, где-то что-то перепутал), заткнув которые, я получил работающую программу.
Я, конечно, на Python столько не писал, но боюсь представить, как бы эти ошибки затыкались на Python'е. Либо тесты на это дело таки должны быть (и всё равно проверка только после запуска), либо будет страшный страх.
Честно говоря, аргумент «не серебряная пуля» и «не гарантирует» на самом деле всё больше начинает радовать. Это ли не доказательство (ну, не доказательство, конечно, но на мысли наводит) того, что больше аргументов нет, раз прибегают к неоспоримым, но при этом совершенно бессмысленным?
Никто и не утверждает, что типизация — серебряная пуля. Это просто другой инструмент проверки программ, но у Haskell есть одно преимущество — у него этот инструмент есть. Ещё более мощный инструмент есть у Agda2, например. А вот когда выгодно воспользоваться одним, а когда другим (тестированием), решать уже программисту.
Тестировать Haskell программу нужно, только для других языков нужны в том числе огромное кол-во и тех тестов, которые typechecker'ом Haskell отметаются, а в другом языке выбора нет.
Не понял, несоблюсти какую симметричность?
Я по крайней мере точно уверен, что элементы пары случайно никто не поменяет местами, и уж тем более не передаст нечисла. Можно получить и более строгую гарантию при желании.
Сложность там излишня для конкретного примера — написанного на скорую руку простого алгоритма, в котором и ошибиться-то негде. На Питоне следовало бы для более полного сравнения наваять тестов, а потом проверить возможность отрефакторить, чтобы ничего не сломалось. Я так понимаю, пугает всех наличие всяких fmap runStateT, ну так это разумная плата за мощную типизацию и контроль.
Типы тоже иногда приходится указывать, некоторые даже говорят, что они не нужны, однако бенефиты от типов многим видны.
Здесь аналогично, да, приходится явно указывать — тут у меня состояние, тут исключения, однако лично мне это помогает понимать код, плюс ощущение, что практически любой скомпилированный код будет работать сразу же, у меня появилось только при использовании Haskell.
А рефакторинг на нём делать вообще сказка. Так что экстраполировать на средние и большие проекты точно не стоит. Там всё совсем по-другому. Я не говорю, что там сплошные плюсы, но уж слишком разные параметры имеют значение.
Вывод о сложности кода на Хаскеле почти всегда делают те, кто на нём особо и не писал. Язык должен быть понятен тем, кто его знает, а не всем. В этом плане Haskell как раз очень хорош, чужой код на нём читается достаточно просто, именно благодаря Bondage&Discipline.
А благодаря искусственным ограничениям решение «в лоб» часто оказывается слишком неэстетичным (мутабельность-то есть, но десять раз подумаешь, прежде чем её вставить), а потому приходится думать над более простым решением. Я нередко сам сталкивался с тем, что в итоге решение получается наоборот простым. Т.е. всё с точностью до наоборот. Подходы-то сложные, зато решение проще и понятнее.
Это, конечно, субъективное мнение, но основано на достаточном опыте, а не на поверхностном знакомстве.
HippoEDIT.
Я не думаю, что он умеет больше, чем большинство остальных, просто я к нему привык, да и особых запросов у меня нет.
Пробовал также TextAdept (скриптуется Lua), жду стабильной кросс-платформенной версии для Yi.
Насколько я понимаю, от реестра рекомендуют отказаться не потому, что он не файловый, в противном случае можно было бы ничего не менять и сделать, как вы сказали.
Так что под «выкинуть» реестр я понял именно убирание того нежелательного реестра, чтобы в него нельзя было писать, а как именно он реализован, уже не суть.
Можете уточнить, с чем именно, не описываемым математикой, мы сталкваемся в Haskell при вводе-выводе?
С задачами же распознавания образов все, по-моему, достаточно банально — там нужна высокая производительность.
Быдлопрограммистам писать проще на языках с низким порогом вхождения, так как высокий порог вхождения они осилить почти не в состоянии.
Когнитивный диссонанс возникает от того, что люди сначала думают, что «быдлоязык = плохой язык», а потом упорно это пытаются опровергнуть фразами типа «не язык плохой, а программисты на нём плохие», как будто сам язык абсолютно никак не связан с программистами, на нём пишущими.
К.О.
--interactive— интерпретатор.runghc — программа, выполняющая исходник без компиляции (т.е. в отличие от интерпретатора, не интерактивная сессия, а просто runghc some.hs), в данном случае как раз, по-моему.
В Haskell благодаря чистоте это не имеет значения, а благодаря монадам я всегда могу указать «направление».
Например, распечатка списка в прямом порядке:
foldr ((>>).print) (return ()) [1,2,3],а вот в обратном:
foldr ((flip (>>)).print) (return ()) [1,2,3]В остальных языках монады тоже есть, но они вшиты в язык, потому не видны, но и управлять ими возможности нет.
Чтобы иметь возможность обитать на 10-м этаже, иногда приходится спускаться на 2-й сложным способом. Другие предпочитают подниматься не выше 5-го.
> Глобальные переменные и побочные эффекты — не единственные проблемы в программировании
Дык! Поэтому хотят вообще возможность в типе функции указать, что она не просто осуществляет ввод-вывод, а ровно в тот Handle, который ей передали, а не куда-то ещё, но это пока слишком круто ;)
Программист может решать сам, мутабельные переменные есть, dynamic есть, template haskell есть. Другое дело, что выглядит это страшновато, но тут на самом деле вопрос баланса. Сделай удобным — начнут пользоваться, где попало, что плохо. А вот где эта золотая середина — сказать сложно.
Т.е. если очень нужно, оно есть, пусть решает программист, но сначала подумает, а дейсвительно ли нужно.
Тот, кто захочет заменить способ хранения графа, конечно, не дурак, но что же, все недураки перед рефакторингом сидят и помечают все места, где надо не забыть заменить код? А в старый код ещё и вникать придётся. Какая-то monkey-work, честное слово. Достаточно где-то не заменить функцию, и ловим ошибки во время работы программы. Я же иногда даже просто беру и меняю тип данных. Всё. Далее мне компилятор сам выдаст все места, где надо поправить (тут, кстати, играет роль не только система типов, но и различие написания конструкторов и переменных и прочее), а там я уже решаю, нужно тут вникать, или сделать тривиальное изменение.
Разные вспомогательные функции в Haskell'е легко и просто описываются такой замечательной штукой, как undefined. Если вы не случайно ошиблись, а именно что хотите временно отложить написание или исправление — undefined вам в руки, сам пользуюсь, так что это надуманная проблема.
Я не доверяю ни Васе Пупкину, ни Пете Васечкину, но в Haskell'е я по типу вижу (без всяких доверий), что функция не меняет глобальных переменных и не пишет в лог. А захоти я изменить тип графа, я его просто поменяю, а потом исправлю ошибки типизации. И с большой вероятностью, ничего не сломается. Тут мы и подходим к вопросу разработки больших систем, когда я предпочту не вникать в код, если этого можно избежать.
Как это не факт? Всё, что придётся тестировать на Haskell, придётся тестировать и на Python'е. Плюс как минимум типы. Я тут на днях переворачивал вверх дном код, так повылазило очень много ошибок типизации (где-то недосмотрел, где-то что-то перепутал), заткнув которые, я получил работающую программу.
Я, конечно, на Python столько не писал, но боюсь представить, как бы эти ошибки затыкались на Python'е. Либо тесты на это дело таки должны быть (и всё равно проверка только после запуска), либо будет страшный страх.
Никто и не утверждает, что типизация — серебряная пуля. Это просто другой инструмент проверки программ, но у Haskell есть одно преимущество — у него этот инструмент есть. Ещё более мощный инструмент есть у Agda2, например. А вот когда выгодно воспользоваться одним, а когда другим (тестированием), решать уже программисту.
Тестировать Haskell программу нужно, только для других языков нужны в том числе огромное кол-во и тех тестов, которые typechecker'ом Haskell отметаются, а в другом языке выбора нет.
Я по крайней мере точно уверен, что элементы пары случайно никто не поменяет местами, и уж тем более не передаст нечисла. Можно получить и более строгую гарантию при желании.
fmap runStateT, ну так это разумная плата за мощную типизацию и контроль.Типы тоже иногда приходится указывать, некоторые даже говорят, что они не нужны, однако бенефиты от типов многим видны.
Здесь аналогично, да, приходится явно указывать — тут у меня состояние, тут исключения, однако лично мне это помогает понимать код, плюс ощущение, что практически любой скомпилированный код будет работать сразу же, у меня появилось только при использовании Haskell.
А рефакторинг на нём делать вообще сказка. Так что экстраполировать на средние и большие проекты точно не стоит. Там всё совсем по-другому. Я не говорю, что там сплошные плюсы, но уж слишком разные параметры имеют значение.
А благодаря искусственным ограничениям решение «в лоб» часто оказывается слишком неэстетичным (мутабельность-то есть, но десять раз подумаешь, прежде чем её вставить), а потому приходится думать над более простым решением. Я нередко сам сталкивался с тем, что в итоге решение получается наоборот простым. Т.е. всё с точностью до наоборот. Подходы-то сложные, зато решение проще и понятнее.
Это, конечно, субъективное мнение, но основано на достаточном опыте, а не на поверхностном знакомстве.
У Си++ ошибок нет: codepad.org/d7zcDXam
Я не думаю, что он умеет больше, чем большинство остальных, просто я к нему привык, да и особых запросов у меня нет.
Пробовал также TextAdept (скриптуется Lua), жду стабильной кросс-платформенной версии для Yi.
Так что под «выкинуть» реестр я понял именно убирание того нежелательного реестра, чтобы в него нельзя было писать, а как именно он реализован, уже не суть.
С задачами же распознавания образов все, по-моему, достаточно банально — там нужна высокая производительность.