![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Левенчук пишет, что все серьёзные программисты мечтают программировать на фукнциональных языках. Не знаю, как серьёзные, а у меня лично никогда желания программировать на Лиспе не возникало. Нечеловеческий он какой-то. Пусть ворлоны на нём программируют.
Tags:
Re: ага, а вот и флейм!
опять об тоже место
угу.
> в Лиспе нельзя не пользоваться императивными возможностями
а каким боком циклы обязательно "императивны", не подскажешь?
(то есть про необходимость как-то ¨деструктивно¨ апдейтить переменные, в которых сидит loop state, я вполне понимаю. но считать на данном основании любой цикл императивным — чистой воды академическое крючкотворство, и ты это, надеюсь, прекрасно понимаешь. если подходить с подобной логикой, то функциональных языков вообще в природе нету, поскольку всё в конце концов превращается в ни разу не функциональный Мойшинный Кодъ).
> Предложение не пугать человека хвостовыми рекурсиями выглядит в этом контексте, мягко гойворя, странным
и пойчему? показывать собственную образованность — это одно, а пытаться что-то действительно объяснить (в смысле так чтобы поняли и не ушли в несущественные дебри) — другое.
Re: опять об тоже место
Таким, что неимперативный цикл сводится к хвостовой рекурсии.
> но считать на данном основании любой цикл императивным — чистой воды академическое крючкотворство, и ты это, надеюсь, прекрасно понимаешь.
Это крючкотворство абсолютно необходимо, когда ты пишешь компиляторы. Практика требует. Есть в конструкции сайд-эффект - теряем сразу огромное количество возможностей статического анализа и оптимизаций, нет сайд-эффектов - делаем с ней всё, что угодно.
> если подходить с подобной логикой, то функциональных языков вообще в природе нету, поскольку всё в конце концов превращается в ни разу не функциональный Мойшинный Кодъ).
Зависит от того, на каком этапе компиляции эта неиллюзорная мойшинная императивность вылезает. Разница чисто практическая, в удобстве анализа и оптимизации.
Re: опять об тоже место
что является типичным времяпровождением любого практикующего программиста, не так ли?
Re: опять об тоже место
Каждая большая задача лучше всего решается именно таким образом: придумывается язык, заточенный под предметную область этой задачи, пишетя абы какая его реализация, задача в пол-пинка решается, заказчик почти-доволен, пишем эффективную реализацию языка.
Интересно, что ты считаешь за среднестатическое промышленное программирование?
Re: опять об тоже место
тут надо с 17-го году начинать, видимо.
накатаю отдельный пост, вот только ребёнка спать отложу...
Re: опять об тоже место
> Каждая большая задача лучше всего решается именно таким образом: придумывается язык, заточенный под предметную область этой задачи
исходя из моего опыта, могу сказать что дело выглядит так: для большой задачи выдумывается подходящая ей нотация. я не употребляю здесь слово "язык" намеренно, поскольку термин это нагруженный и будящий ассоциации с "Тьюринг-полнотой". каковой полноты во всех выдуманных за мою карьеру lisp-based "little languages" не наблюдалось и в помине. соответственно, никакой нетривиальной компиляции тоже не требовалось. что и правильно, поскольку language design & implementation есть дело тонкое, сурьёзное и чрезвычайно трудоёмкое (ага, придумал язык, не преобразующийся тривиально в CL, а требующий компиляции с интерпретацией? молодец! а как насчёт отладчик к нему написать? а профилятор не хотите ли? ну, понятно), и к вящей радости CL позволяет до этого не доводить.
теперь по поводу моей несколько, видимо, странно выглядящей бурной реакции на твой первый коммент. дело в том, что ты ухитрился нажать сразу на несколько моих любимых кнопочек (либо мне показалось, что ты это сделал, тады типа извини).
напоминаю: ты заявил, что отсутствие хвостовой рекурсии является "бядой" CL. в данной коротенькой фразе содержится следующий комплект раздражающих утверждений:
1. функциональное программирование — это хорошо, а если совсем функционально нельзя, то это плохо.
2. (в контексте разговора с человеком, ничего ни про Лисп, ни про функциональное программирование, окроме общепринятого мудового фольклора, не знающем) CL говно, потому что не гарантирует хвостовую рекурсию.
3. автор утверждения — академик.
тему номер 3 я развивать здесь далее не намерен, с твоего позволения; она большая слишком и отдельная.
номер 2, как сказано, существует благодаря контексту. в самом лучшем случае это просто лишняя информация. кроме того, это утверждение истинно лишь если придерживаться догмы о том, что функциональное программирование есть гут, а его неполное присутствие есть нот гут, о чём ниже.
номер 1 требует небольшого экскурса в суть. функциональное программирование продаётся как хорошая вещь, поскольку сильно ограничивает возможности программиста пальнуть себе в ногу. именно продаётся: недаром при этом используются качественные определения типа "pure functional". pure — это ведь так хорошо! а impure — уже не так хорошо, правда ведь?
тогда как на деле ФП — это всего лишь один из способов увести программирование в сторону декларативности и (как следствие) простоты. есть и другие способы упростить нотацию, которые не требуют обязательного отказа от side effects (как это по-русски, а?). более того, во многих случаях нарочитый отказ от этих самых side effects лишь запутывает логику программы, ибо в т.н. "реальной жизни" большинство программ не высчитывают результаты волосатых математических формул, а манипулируют разного рода сохраняемую информацию: т.е. смысл их существования и ядро их логики — это именно эти вот самые side effects.
взамен незамутнённому практикой функциональному программированию CL предлагает нечто куда более ценное: возможность структурировать эти самые неизбежные в т.н. "реальной жизни" side effects посредством протоколов и возможность создавать специализированную декларативную нотацию для конкретных задач посредством макросов. ценность CL именно в том и состоит, что я не должен выгибать логику программы в сторону чистого ФП, или в сторону чистого predicate calculus типа как в Прологе, или в сторону message-passing "OOP" типа как в Смолтоке и Жабе, или в сторону total fucking nightmarish brain damage как в C++.
Re: опять об тоже место
По поводу 1) - этого я нигде не утверждал. ФП - лишь одна из семантик, применимая далеко не для каждой предметной области.
2) Этого тоже я не утверждал - я лишь подчеркнул, что Лисп не просто не функциональный, а он вообще не может быть функциональным, не смотря на наличие функциональных конструкций - просто нельзя на нём чисто функционально писать.
3) С какой это радости? Вот уж кем я себя никогда не считал. Даже когда я работал в науке, это было чисто индустриальное программирование - в экспериментальной физике высоких энергий и в феноменологии как-то нет смысла заниматься академическим computer science, задачи там сугубо практические и крайне суровые. Сейчас же я и вовсе в абсолютно коммерческой индустрии работаю. С академическим computer science сильно не дружу, во многом по тем же причинам, что и Пол Грэхем - уж больно они все подвинулись на типах...
> есть и другие способы упростить нотацию, которые не требуют обязательного отказа от side effects (как это по-русски, а?).
Советую не забывать и про удобство для статического анализа кода - иногда это - фатальное требование. Отследить сайд-эффекты (никогда не знал русского аналога!) автоматом - лучше сразу застрелиться... Dataflow-analisys - задача дико нетривиальная и ресурсоёмкая.
> т.е. смысл их существования и ядро их логики — это именно эти вот самые side effects.
Часто есть смысл отказаться от рассмотрения предметной области в столь низкоуровневых терминах, как какие-то там хранилища данных и транзакции над ними. Логика процессов в реальном мире декларативна. Естественно, я не призываю заворачивать ввод-вывод в монады, и радоваться, какое всё чистенькое-функциональненькое - пусть оно на низком уровне остаётся понятным и императивным. На уровне описания логики лучше обходиться без императивных конструкций - там они становятся неестественными.
С последним абзацем - абсолютно согласен. У меня вообще поверх CL иногда дикая каша получается - ленивый функциональный язык для написания макр (ну удобно компиляторы писать на таких языках, там никакого I/O, сплошной pattern matching), целевой язык - нечто фортообразное и отдельно прологообразное, с оптимизирующей компиляцией (всё - на уровне макр) в тот же Common Lisp и SQL.
Ещё смешнее, что я сейчас достраиваю аналогичную систему поверх Java. Благо, динамически генерять код там легко, а интерпретатор ленивой функциональщины в пол-пинка делается. И стала Жаба в результате неотличима от Common Lisp-а, он получается одним из промежуточных языков...