История изменений
Исправление Nervous, (текущая версия) :
вообще не понимаешь о чем говоришь
Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у
тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.
Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.
В кложе ничего искать и ничего писать не надо, вся стандартная библиотека (а также куча сторонних) без проблем с иммутабельными коллекциями работает. Более того, можешь выкатить свою реализацию, и с ней стандартная библиотека будет работать тоже. Потому что построена вокруг абстракций, а не конкретного cons cell.
Вот этим современный лисп и отличается от архаичного — он движется вперёд, стремится пользоваться накопленным (в основном другими, конечно) опытом, не пренебрегать работой над ошибками, осознавать и решать современные проблемы, облегчать людям работу — а не почивать на лаврах хренадцатилетней давности, делая вид, что ничего в мире вычислений с тех пор не изменилось и что кроме «гибкости», больше ничего не нужно. С закономерным результатом.
понятия не имеешь о гибкости CL и его реализаций
Эта «гибкость» на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)
Исправление Nervous, :
вообще не понимаешь о чем говоришь
Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у
тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.
Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.
В кложе ничего искать и ничего писать не надо, вся стандартная библиотека (а также куча сторонних) без проблем с иммутабельными коллекциями работает. Более того, можешь выкатить свою реализацию, и с ней стандартная библиотека будет работать тоже. Потому что построена вокруг абстракций, а не конкретного cons cell.
Вот этим современный лисп и отличается от архаичного — он движется вперёд, стремится пользоваться накопленным (в основном другими, конечно) опытом, не пренебрегать работой над ошибками, осознавать и решать современные проблемы, облегчать людям работу — а не почивать на лаврах хренадцатилетней давности, делая вид, что ничего в мире вычислений с тех пор не изменилось и что кроме «гибкости», больше ничего не нужно. С закономерным результатом.
понятия не имеешь о гибкости CL и его реализаций
Эта гибкость на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)
Исправление Nervous, :
вообще не понимаешь о чем говоришь
Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у
тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.
Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.
В кложе ничего искать и ничего писать не надо, вся стандартная библиотека (а также куча сторонних) без проблем с иммутабельными коллекциями работает. Более того, можешь выкатить свою реализацию, и с ней стандартная библиотека будет работать тоже. Потому что построена вокруг абстракций, а не конкретного cons cell.
Вот этим современный лисп и отличается от архаичного — он движется вперёд, стремится пользоваться накопленным (в основном другими) опытом, не пренебрегать работой над ошибками, осознавать и решать современные проблемы, облегчать людям работу — а не почивать на лаврах хренадцатилетней давности, делая вид, что ничего в мире вычислений с тех пор не изменилось и что кроме «гибкости», больше ничего не нужно. С закономерным результатом.
понятия не имеешь о гибкости CL и его реализаций
Эта гибкость на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)
Исправление Nervous, :
вообще не понимаешь о чем говоришь
Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у
тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.
Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.
В кложе ничего искать и ничего писать не надо, вся стандартная библиотека (а также куча сторонних) без проблем с иммутабельными коллекциями работает. Более того, можешь выкатить свою реализацию, и с ними стандартная библиотека будет работать тоже. Потому что построена вокруг абстракций, а не конкретного cons cell.
Вот этим современный лисп и отличается от архаичного — он движется вперёд, стремится пользоваться накопленным (в основном другими) опытом, не пренебрегать работой над ошибками, осознавать и решать современные проблемы, облегчать людям работу — а не почивать на лаврах хренадцатилетней давности, делая вид, что ничего в мире вычислений с тех пор не изменилось и что кроме «гибкости», больше ничего не нужно. С закономерным результатом.
понятия не имеешь о гибкости CL и его реализаций
Эта гибкость на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)
Исправление Nervous, :
вообще не понимаешь о чем говоришь
Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у
тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.
Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.
В кложе ничего искать и ничего писать не надо, вся стандартная библиотека (а также куча сторонних) без проблем с иммутабельными коллекциями работает. Более того, можешь выкатить свою реализацию, и с ними стандартная библиотека будет работать тоже. Потому что построена вокруг абстракций, а не конкретного cons cell.
Вот этим современный лисп и отличается от архаичного — он движется вперёд, стремится пользоваться накопленным (в основном другими) опытом, не пренебрегать работой над ошибками, осознавать и решать современные проблемы и облегчать людям работу — а не почивать на лаврах хренадцатилетней давности, делая вид, что ничего в мире вычислений с тех пор не изменилось и что кроме «гибкости», больше ничего не нужно. С закономерным результатом.
понятия не имеешь о гибкости CL и его реализаций
Эта гибкость на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)
Исходная версия Nervous, :
вообще не понимаешь о чем говоришь
Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у
тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.
Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.
В кложе ничего искать и ничего писать не надо, вся стандартная библиотека (а также куча сторонних) без проблем с иммутабельными коллекциями работает. Более того, можешь выкатить свою реализацию, и с ними стандартная библиотека будет работать тоже. Потому что построена вокруг абстракций, а не конкретного cons cell.
Вот этим современный лисп и отличается от архаичного — он движется вперёд, стремится пользоваться накопленным (в основном другими) опытом, осознавать и решать современные проблемы и облегчать людям работу — а не почивать на лаврах хренадцатилетней давности, делая вид, что ничего в мире вычислений с тех пор не изменилось и что кроме «гибкости», больше ничего не нужно. С закономерным результатом.
понятия не имеешь о гибкости CL и его реализаций
Эта гибкость на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)