Здравствуйте, novitk, Вы писали:
N>Возник вопрос на который не могу сходу ответить. Почему бы не сделать неявный каст в грязь, если хотя бы один из параметров чистой HOF грязный, тo есть просто разрешить выражение "pureHOF(&dirtyFunc)" в грязной функции?
Т.е. у функции на лбу в сигнатуре будет написано, что она чистая, но вот в этом месте она окажется грязной. Нафиг тогда вообще на ней что-то писать? Сейчас, когда ФВП делаются с шаблонными параметрами, все и так получается автоматически: передал ей грязную ф-ю, получил грязную, передал чистую — получил чистую. Не нужны никакие касты.
alex_public,
NL>>То есть ты считаешь, что запреты — это плохо и это ограничивают наш полёт мысли, правильно? И чем меньше ограничений, тем выше полёт мысли?
_>Если мы говорим про язык, то безусловно. Язык должен предоставлять мне инструменты, с помощью которых я будут устанавливать нужные мне в данном проекте запреты. А не устанавливать их сам за меня, причём некие неудобные универсальные.
Звучит как coding standard принятый в рамках проекта.
_>Да ничего в нём (Haskell) нет сложного. Просто неудобен он почти для всех применений. За исключением разве что написания каких-нибудь консольных утилит анализа/трансформации файлов и т.п. приложений.
Звучит как заблуждение.
NL>>А мультипарадигменность из коробки с одной стороны позволяет программисту Васе в D писать как на фортране или Пете — как на джаве, а с другой стороны выходит боком в долгосрочной преспективе — примеров тому предостаточно.
_>В долгосрочной перспективе всё очень хорошо видно здесь: http://www.tiobe.com/tiobe-index/ )))
Там дельфи и бейсик в топах. И ещё недавно выкопанный зомби по имени Dart. Ещё Perl почти наравне с Javascript. Ты серьёзно?
NL>>Когда в языке из коробки нет, например, наследования и обработки исключений — это сразу делает язык гораздо проще для реализации и для изучения. И соотвественно шансы стать массовым увеличиваются.
_>Это речь про Go? )))
Да, Go. И если вспомнить языки просто без наследования (js, vba), то можно заметить, сколько граблей обойдено разом просто за счёт этого. И Бьярн тоже разделяет эту мысль.
Здравствуйте, D. Mon, Вы писали:
DM>Т.е. у функции на лбу в сигнатуре будет написано, что она чистая, но вот в этом месте она окажется грязной. Нафиг тогда вообще на ней что-то писать?
С ФВП ничего не произошло, так как она сама по себе не добавляет sideeffect-ов. Результат ее применения к грязной функции очевидно загрязняет enclosing closure.
DM>Сейчас, когда ФВП делаются с шаблонными параметрами, все и так получается автоматически: передал ей грязную ф-ю, получил грязную, передал чистую — получил чистую. Не нужны никакие касты.
Сейчас в D утинная типизации шаблонов, как в плюсах. Собственно я посмотрел https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d и там вполне себе обычная плюсовая наркота. Вот из этого "template map(fun...) if (fun.length >= 1)" и страницы кода тип fun человеком не выводится. То есть пишем/читаем доки и получаем говноошибки. Все как в плюсах. Еще и очевидно для оптимизаций сделали map двухмерных. Модульность? Нет, не слышали.
Ты только не думай что я на твои игрушки наезжаю. Сам на Скале и в коллекциях там наркоты не меньше (builder-ы и прочий бред), но типизация параметров ФВП там все же есть.
Здравствуйте, Nick Linker, Вы писали:
_>>Если мы говорим про язык, то безусловно. Язык должен предоставлять мне инструменты, с помощью которых я будут устанавливать нужные мне в данном проекте запреты. А не устанавливать их сам за меня, причём некие неудобные универсальные. NL>Звучит как coding standard принятый в рамках проекта.
coding standard к сожалению не проверяются компилятором. )
Речь немного о другом. Что в своём (нормальном мультипарадигменном) языке я могу легко добиться иммутабельного поведения любой нужной мне переменной. Но я не хочу что бы все переменные в проекте были иммутабельными. Понятна мысль? )
_>>Да ничего в нём (Haskell) нет сложного. Просто неудобен он почти для всех применений. За исключением разве что написания каких-нибудь консольных утилит анализа/трансформации файлов и т.п. приложений. NL>Звучит как заблуждение.
Хех, на эту тему на данном форуме уже были флеймы дикой длины. Повторяться нет никакого желания. Тем более, что никаких новых аргументов за эти годы не добавилось ни с одной стороны.
_>>В долгосрочной перспективе всё очень хорошо видно здесь: http://www.tiobe.com/tiobe-index/ ))) NL>Там дельфи и бейсик в топах. И ещё недавно выкопанный зомби по имени Dart. Ещё Perl почти наравне с Javascript. Ты серьёзно?
Ну если тебя не устраивает данный рейтинг, то приведи свой, более авторитетный на твой взгляд. Посмотрим какие там места занимают мультипарадигменные языки. )
NL>Да, Go. И если вспомнить языки просто без наследования (js, vba), то можно заметить, сколько граблей обойдено разом просто за счёт этого. И Бьярн тоже разделяет эту мысль.
По поводу Go лично у меня основная претензия в другом (претензия на уровне абстрактного мнения о языке — переходить на что-то подобное у меня потребности нет в любом случае, даже если бы не было претензий). На мой вкус современный статических типизированный язык не поддерживающий парадигму обобщённого программирования (пускай даже на уровне убогих дженериков, как в Java/.Net) не имеет права на существование.
alex_public,
_>Речь немного о другом. Что в своём (нормальном мультипарадигменном) языке я могу легко добиться иммутабельного поведения любой нужной мне переменной. Но я не хочу что бы все переменные в проекте были иммутабельными. Понятна мысль? )
Эта мысль весьма противоречива в своей сущности:
1. С одной стороны есть теорема Райса, которая накладывает принципиальные ограничения на статический анализ
2. С другой стороны для выполнения преобразований с АСТ (например инлайнинг, фьюжн, частичное применение) компилятору необходимы консервативные предположения (как можно более полная информация о типах, чистота, иммутабельность)
3. Ты хочешь уничтожить некоторые из предположений, что поставит крест на применимости анализа и преобразований
4. Таким образом ты говоришь "эй, компилятор, я знаю как лучше, отойди в сторонку и не мешай!", и в сущности начинаешь делать его работу
5. И это язык программирования будущего.
Я правильно понял твою мысль?
_>Хех, на эту тему на данном форуме уже были флеймы дикой длины. Повторяться нет никакого желания. Тем более, что никаких новых аргументов за эти годы не добавилось ни с одной стороны.
Возможно кто-то из не учавствовавших в этих "флеймах дикой длины" теперь пишет код на Хаскеле просто на работе и видит своими глазами, что неудобство только одно — невозможно так просто "х*як-х*як и в продакшен" — компилятор сильно мешает. Так что про "консольные утилиты" — это не более чем заблуждение.
Этот аргумент был: State of the Haskell ecosystem?
_>По поводу Go лично у меня основная претензия в другом (претензия на уровне абстрактного мнения о языке — переходить на что-то подобное у меня потребности нет в любом случае, даже если бы не было претензий). На мой вкус современный статических типизированный язык не поддерживающий парадигму обобщённого программирования (пускай даже на уровне убогих дженериков, как в Java/.Net) не имеет права на существование.
Но он однако существует и похоже становится сильно популярным. Жаль, но так работает популярность — куда легче вход, туда и идут массы.
D. Mon,
NL>>4. Таким образом ты говоришь "эй, компилятор, я знаю как лучше, отойди в сторонку и не мешай!",
DM>А лучше "эй, компилятор, иди сюда и активно мешай"? DM>Приседать и бегать в мешках ради удобства компилятора?
Отрицанием фразы "отойди и не мешай" является "не отходи или мешай" — и как правило мы не просим компилятор о втором.
Но вообще, да, приходится бегать в мешках, а что делать? Можно назвать "бег в мешках" умным термином, скажем "сигнатура функции", "метапрограммирование" или там "статический инвариант", и будет не обидно Но это нужно делать.
Здравствуйте, Nick Linker, Вы писали:
_>>Речь немного о другом. Что в своём (нормальном мультипарадигменном) языке я могу легко добиться иммутабельного поведения любой нужной мне переменной. Но я не хочу что бы все переменные в проекте были иммутабельными. Понятна мысль? ) NL>Эта мысль весьма противоречива в своей сущности: NL>1. С одной стороны есть теорема Райса, которая накладывает принципиальные ограничения на статический анализ NL>2. С другой стороны для выполнения преобразований с АСТ (например инлайнинг, фьюжн, частичное применение) компилятору необходимы консервативные предположения (как можно более полная информация о типах, чистота, иммутабельность)
Совершенно верно. И в нормальном языке мы стараемся указать компилятору максимум информации. Например мутабельная данная переменная или иммутабельная. Чистая у нас функция или нет. И т.д. и т.п. Т.е. я как раз за максимально подробную статическую типизацию из которой компилятор сможет сделать максимум выводов.
NL>3. Ты хочешь уничтожить некоторые из предположений, что поставит крест на применимости анализа и преобразований
Не уничтожить, а местами заменить другими предположениями (кстати подобное нагляднее всего можно увидеть в каком-нибудь Rust'е, где иммутабельное поведение тоже подразумевается, но есть модификатор mut для изменения поведения переменной).
NL>4. Таким образом ты говоришь "эй, компилятор, я знаю как лучше, отойди в сторонку и не мешай!", и в сущности начинаешь делать его работу
Ну так это смотря какой компилятор.
Скажем компилятору C++ уже давно перестали пытаться такое говорить (хотя когда-то пытались, всяческими указаниями на inline, ассемблерными вставками и т.п.), потому как он отлично справляется со своими задачами.
А вот компилятору Хаскеля как раз очень не плохо было такое сказать во многих местах, в которых он навязывает использование неэффективных для данного алгоритма иммутабельных переменных. Только вот к сожалению в языке для этого не существует инструментов (нет ухода на низкий уровень, где естественно всё мутабельное, т.к. именно так устроены современные процессоры и память), поэтому в большинстве случаев просто выкидывается на свалку весь язык целиком.
NL>5. И это язык программирования будущего.
Не знаю что ты называешь языком будущего. Но например за последние несколько лет одна из самых интересных на мой взгляд инноваций (именно реально чего-то нового, а не очередного воплощения идей 60-70 годов) появилась не в каком-то новом языке, а в старичке C++. Это я говорю про семантику перемещения.
_>>Хех, на эту тему на данном форуме уже были флеймы дикой длины. Повторяться нет никакого желания. Тем более, что никаких новых аргументов за эти годы не добавилось ни с одной стороны. NL>Возможно кто-то из не учавствовавших в этих "флеймах дикой длины" теперь пишет код на Хаскеле просто на работе и видит своими глазами, что неудобство только одно — невозможно так просто "х*як-х*як и в продакшен" — компилятор сильно мешает. Так что про "консольные утилиты" — это не более чем заблуждение. NL>Этот аргумент был: State of the Haskell ecosystem?
Хы, ожидал какой-то сомнительной ссылки с рассуждениями "Хаскель круче всех", а тут неожиданно вполне разумный анализ. Разве что слегка промелькнул известный миф о каких-то преимуществах Хаскеля для многопоточности, но это простительно. А так вполне чётко всё изложено. И при этом полностью соответствует моим словам. С оценкой "Best in class" (а я лично только такое и рассматриваю при при выборе инструмента в новой области) там находится ровно один тип ПО, который они обозвали "компиляторами". На мой взгляд это излишне узкое название, а я бы сказал что речь о любых консольных анализаторах (т.е. приложениях, которые при старте читают некие данные, потом выполняют с ними сложные преобразования и в конце выполняют вывод результата). И то это моя оценка, а некоторые местные специалисты по написанию компиляторов говорят что там некоторые самые эффективные алгоритмы парсинга "энергичны и мутабельны".
_>>По поводу Go лично у меня основная претензия в другом (претензия на уровне абстрактного мнения о языке — переходить на что-то подобное у меня потребности нет в любом случае, даже если бы не было претензий). На мой вкус современный статических типизированный язык не поддерживающий парадигму обобщённого программирования (пускай даже на уровне убогих дженериков, как в Java/.Net) не имеет права на существование. NL>Но он однако существует и похоже становится сильно популярным. Жаль, но так работает популярность — куда легче вход, туда и идут массы.
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, в языке D есть pure-функции, но при этом никаких лифтингов ни в какие монады там делать не надо.
Ди — энергичный язык. Ему на фиг не нужны монады для вовода-вывода. У него любая функция может делать ввод вывод. А чистота не более чем вычисляемый атрибут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ди — энергичный язык. Ему на фиг не нужны монады для вовода-вывода.
По-хорошему, энергичность еще ничего не значит. Идрис вон тоже энергичный, но ввод-вывод все равно отражен в монадоподобных типах и do-синтаксисе, просто так в чистой ф-ии строчку не выведешь.
Здравствуйте, D. Mon, Вы писали:
DM>По-хорошему, энергичность еще ничего не значит. Идрис вон тоже энергичный, но ввод-вывод все равно отражен в монадоподобных типах и do-синтаксисе, просто так в чистой ф-ии строчку не выведешь.
Думаю, что ты ошибешься. Я погугли и первое что попалось — это видео где орел без каких либо монад тупо вызывает printf в REPL-е передавая ему значения.
В прочем проблемы с побочными эффектами в Хаскеле связаны не только с ленивость. Главным образом проблема в том, что в Хаскеле вычисления зависимые (не путать с зависимыми типами), а значит их порядок определяется сложным образом (не определяется последовательностью кода в функции). Зависимые вычисления могут быть энергичными. Линивость же приводит к тому, что вычисление может вовсе не быть сделано.
А просто "чистота" ровным счетом ничего не значит. Например, тот же консольный вывод данные не меняет, но побочным эффектом является. Его вполне можно использовать в энергичном языке. Даже если вычисления зависимые консольный вывод произойдет после вычисление его параметров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
DM>>По-хорошему, энергичность еще ничего не значит. Идрис вон тоже энергичный, но ввод-вывод все равно отражен в монадоподобных типах и do-синтаксисе, просто так в чистой ф-ии строчку не выведешь.
VD>Думаю, что ты ошибешься. Я погугли и первое что попалось — это видео где орел без каких либо монад тупо вызывает printf в REPL-е передавая ему значения.
Я на Идрисе писал, представляю о чем говорю. А что за видео ты видел, можно ссылку?
PS. REPL'ы обычно уже в монаде IO или ее аналоге живут, там принты и должны работать сразу. В репле писать это не то же самое, что чистый код.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
теперь пишет код на Хаскеле просто на работе и видит своими глазами, что неудобство только одно — невозможно так просто "х*як-х*як и в продакшен" — компилятор сильно мешает. Так что про "консольные утилиты" — это не более чем заблуждение.
