Здравствуйте, AndreiF, Вы писали:

AF>Здравствуйте, FR, Вы писали:

FR>>Где эти остальные?
FR>>Много людей здесь используют немерле как основной инструмент для работы?

AF>Для работы его не используют по другим причинам. Поддержка IDE пока не очень стабильна, нет инструментов для рефакторинга и прочих приятных вещей. Но личность Влада уж точно не является одной из таких причин А вот в нерабочих условиях я думаю уже довольно многие пробовали с ним работать.

Тогда зачем ты предлагаешь мне его использовать для работы?
А для нерабочих условий (есть и у меня такое хобби) уже образовалась очередь из языков которые было бы интересно посмотреть — поковырять, но времени не хватает а для вас похоже свет клином сошелся на одном языке.

FR wrote:
> А для нерабочих условий (есть и у меня такое хобби) уже образовалась очередь из языков которые было бы интересно посмотреть — поковырять, но времени не хватает а для вас похоже свет клином сошелся на одном языке.
Золотые слова.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Я, как известно, бездельник с широким кругом интересов. То есть я могу себе позволить к абсолютно любой новой идее относиться как "так, что здесь новенького и как это поможет change my mind?" (If It's Not Nailed Down, Steal It — Если это не прибито, укради это).
ЗХ>У меня в принципе нет технологии, которую я собираюсь защищать всю жизнь. Любая новая технология оценивается с 2ух точек зрения:
ЗХ>1. не стоит ли мне перейти на нее прямо сейчас? (не будет ли мне с ней настолько комфортнее, что оно того стоит)
ЗХ>2. какие тут есть новые интересные невиданные мной идеи?

Хорошая позиция. Солидарен с ней. Но для того чтобы она работала нужно всегда помнить, что изучая новое ты (я) Блаб-программист.

ЗХ>По пункту (1) я Немерл не рассматриваю из-за чисто технических причин (я не хочу быть привязанным к .Net и не собираюсь эту тему обсуждать);

Хозяин — барен. Хотя я не согласен, что платформа .Net чем-то ущербна, но позиция понятна. По крайней мере честно высказана. Тут почему-то многие вместо того чтобы сказать подобные твоим словам пускаются в демагогию. Зачем, не ясно.

ЗХ>по пункту (2) я его ковыряю потихоньку и согласен признать, что в нем куча интересного.

Дык тогда надо признать, что это интересное рано или поздно будет в господствующих языках. А значит имеет смысл изучать это новое сейчас, чтобы через ~5 лет успешно применять знания на практике.

ЗХ>Ну, тут я ничего не могу сказать. Если я не могу увидеть, скорее всего я и не вижу, чего я не вижу

Зря подмигиваешь. Я не зря помог тебе найти ту статью Грэхема. Мы действительно не видим приемуществ в вещах которые не понимаем. Для нас они кажутся "излишними сложностями".

ЗХ>Интересно. Можно подробнее?

Подробнее см. карринг и частичное применение.

VD>>5. Сопоставление с образцом (pattrn matching) и алгеброические типы.
ЗХ>Вот как раз сопоставление с образцом я не упомянул среди радикально крутых фич Немерла — исключительно потому, что язык с разумно гибким синтаксисом таки позволяет сделать это в виде библиотеки.

Это большое заблуждение. Ты видимо пропустил наш разговор с FR. Он закончился тем, что я дал ему ссылку на реализацию "думателя" используемого в ОКамле и Немерле:
http://nemerle.org/svn/nemerle/trunk/ncc/typing/DecisionTreeBuilder.n

Это 30 кил навороченнейшего кода основанного на паттерн-матчинге.

ЗХ>

ЗХ>#это воспроизведение кусочка вашего спора с Мамутом Nemerle vs. Erlang. И это чистый Руби
ЗХ>def printTag(*arg)
ЗХ>  arg.pmatch(String){|tag|
ЗХ>    printTag(tag, [])
ЗХ>  } ||
ЗХ>  arg.pmatch(String, []){|tag|
ЗХ>    "<#{tag}>"
ЗХ>  } ||
ЗХ>  arg.pmatch(String, Array){|tag, attr|
ЗХ>    "<#{tag}#{printAttrs(attr)}>"
ЗХ>  } ||
ЗХ>  arg.nomatch!
ЗХ>end
ЗХ>

Это довольно примитивный пример. Более серьезны думаю будет невозможен (паттерны на поля, вложенные паттерны). Ну, и скорость у интерпретирующего решения будет очень низкой.

Ну, да давай проведем следственный эксперемент. Вот придуманный мной пример:

using System.Console;

variant Tree
{
  | Nore { left : Tree; right : Tree; }
  | Leaf { data : string }
  
  public override ToString() : string
  {
    match (this)
    {
      | Nore(left, right) => $"#($left, $right)"
      | Leaf(data)        => $"@($data)"
    }
  }
}

type L = Tree.Leaf;
type N = Tree.Nore;

module Program
{
  Main() : void
  {
    def tree1 = N(L("1"), N(N(L("2"), N(N(L("3"), L("4")), L("5"))), L("6")));
    def tree2 = N(L("1"), N(N(L("2"), N(N(L("3"), L("4")), L("5"))), L("88")));
    def tree3 = N(L("1"), N(N(L("2"), N(L("3"), N(L("4"), L("5")))), L("6")));
      
    def testTree(tree)
    {
      | N(L, N(N(L, N(N(L, L), L("5"))), L(x))) => $"Tree mathed. x=$x ($tree)"
      | _ => $"Tree NOT mathed. ($tree)"
    }
      
    WriteLine(testTree(tree1));
    WriteLine(testTree(tree2));
    WriteLine(testTree(tree3));
    _ = ReadLine();
  }
}

Этот пример сторит 3 дерева и тестирует их с помощью паттерн-матчинга. Вот что этот тест выводит на консоль:

Tree mathed. x=6 (#(@(1), #(#(@(2), #(#(@(3), @(4)), @(5))), @(6))))
Tree mathed. x=88 (#(@(1), #(#(@(2), #(#(@(3), @(4)), @(5))), @(88))))
Tree NOT mathed. (#(@(1), #(#(@(2), #(@(3), #(@(4), @(5)))), @(6))))

VD>>7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет.

ЗХ>И это, если можно, подробнее немножко.

Подробнее лучше у FR. Лично для меня ЯП не имеющий защиты членов. И оперирующий разными странными вещами вроде __хзч__ вряд ли может является приемлемой реализацией ООП. И то что ЯП можно подкрутить на метапрограммировании как-то не очень радует. Ведь есть языки которые не надо подкручивать. А подкручиваение это всегда тормоза (для скриптов) и выбрасывание своего времени.

ЗХ>Ну, это опять же кусочек бесконечного флейма.

Откровенно говоря я не вижу причин для флэйма. Но вижу готовых в него вступить. Так что замнем. И без того пунктов хватает.

ЗХ> Я не готов в него опять встрять.
ЗХ>С одной стороны, перейдя с какой-никакой IDE (VC++)

Поддержка IDE у VC++ очень примитивная.

ЗХ> на полностью текстовые файлы + командный интерпретатор (Ruby и command-line tools из VS), я чувствую себя вполне неплохо.

По программируй пол годика на C# в МЫ 2005 или на Яве в IDEA и уверен, что после этого смотреть на командную строку тебе будет уже не так приятно.

ЗХ>С другой стороны, я не выполнял существенных объемов работы на языках с серьезным IDE с поддержкой рефакторинга, то есть просто не знаю вкуса устриц.

О том и речь. Уверяю тебя это как наркотик. По прошествию некоторого времени ты уже не можешь нормально жить без этого.

ЗХ>Ну, необходимость серьезной смены синтаксиса — вопрос не вполне однозначный.

Речь не о смене синтаксиса. Речь об улучшении языка с целью повышения его уровня. Как правильно заметил Грэхем, порой чтобы сделать некоторую задачу на более низкоуровневом языке нужно написать интерпретатор более высокоуровневого. Так вот расширение синтаксиса — это возможность расширения компилятора основного языка с целю повышения его уровня.

ЗХ>Скриптовые языки, хотя и не позволяют определить настолько явно новые элементы, как Немерле (то есть полный syntax definition) имеют разумную гибкость и лаконичность синтаксиса, чтобы считать их возможности расширения неплохими.

Ну, вот Немереле тоже не позволяет сделать это на 100%. Но я уверен, что его разумные пределы более широки и это более разумно. Причем надо учитывать, то что без информации о типах многое сделать не удается. А скриптовые метасредсва основанны на тексуальных движках. Плюс в них вообще не просто получить информацию о типах (она динамична). Это не позволяет реализовать некоторые задумки. А значит мы имеем место меенее мощьного решения.

К тому же я не упомянул об одно мощьном решении — о контроле инвариантов во время компиляции. Это следующих шаг в развитии ЯП. И но по понятным причинам недоступен скриптам.

VD>>12. Производительность получаемого кода. Тут у нас резко пролетают все скрипты.

ЗХ>Ну, тут же опять можно вернуться к вопросу "достаточной производительности". Поэтому мне тяжело назвать это "фичей, повышающей мощность на порядок".

Можно. Но я еще не видел задач где производительность была бы лишней. Обычно мы встаем перед выбором более простых но менее быстрых решений или более сложных, но более оптимальных по скорости. Так вот десятикратный запас позволяет нам выбирать более простые решения.

ЗХ>Итого, (не считая пока фич, для которых я попросил объяснений), остается статическая типизация и ее производные (строгость, серьезная поддержка со стороны IDE). Так?

Не так. Проблема в том, что ты смотришь на языки с точки зрения менее мощьного языка. И от того тебе кажется, что что-то не важно, а что-то является всего лишь непонятным извращением. И до тех пор пока ты не освоищь более мощьный язык ты так и не будешь видеть все правды.

Возвращаясь к разговору о многомерности в фичах могу сказать, что реально из приемуществ скриптов у нас остается только возможность менять типы на ходу (без остановки приложения). Это вряд ли серьезно поднимает мощьность языков. И в итоге даже если исходить из твоих позиций мы (точнее ты) имеем паритет. А раз так, то выбор в пользу языка с мощьной IDE, быстрым конечным кодом является очевидным. Так что на весах у нас явный прогресс против нежелания иметь дело с .NET. Возможно кому-то такое протиповопоставление кажется серьезным. Не спорю.

ЗЫ

В любмо случае хочу сказать спасибо за достойный уровень осбуждения! Приятно увидить достойного оппонента в море подобного

Автор: eao197
Дата: 23.11.06

хамстава и невежества.

Здравствуйте, eao197, Вы писали:

VD>>Теперь остается пробежать список и понять, что в итоге Немерле остался в одиночистве. Все конкуренты отсеялись на тех или иных этапах.

E>Очень похоже, что есть четыре градации лжи: просто ложь, наглая ложь, статистика и сравнение языков программирования от VladD2.

Очень показательное высказывание демонстриующее уровень аргументации.
Продолжай унижаться дальше.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Лучше предметно ответь с чем не согласен, в противном случае лучше промолчать (достаточно -1 поставить).

Да пусть унижается. Может человеку нравится подобное амплуа?

Здравствуйте, eao197, Вы писали:

E>a) почему в отношении ФВП Scala уступает Nemerle?

Скала здесь была пропущена по случайности. Думаю, всем не предвязтым читателям это было очевидно хотя бы из заключительного слова.

E>b) до чего именно ООП в Ruby не дотягивает?

Тем что он ниже плинтуса. Нет даже примитивной защиты.

E>c) почему в плане встроенной поддержки параллелизма не рассматриваются Actor-ы в Scala?

В Скале нет встроенной поддержки параллелизма. Она выполнена в виде библиотеки и по признанию автора работает существенно медленее чем аналогичная а Эрлэнге. Как бы там ни было, но то что реализуется библиотекой не может являться приемуществом языка. Хотя в данном случае я отдал должное Эрлэнгу.

E>d) почему расширяемость языка считается неоспоримым достоинством?

Потому что нужно было внимательно читать приведенную в начале письма цитату. Расширяемый язык мощьнее не расширяемого просто потому, что он может впитывать остуствующие возможности. Замечательными примерами того являются макросы Late и Lazy привносящие в Немерле динамику и ленивые вычисления. Вот когда, например, Руби сумеет включать в себя (средствами мета-программирования) участки статически тпипизированного кода, тогда можно будет назвать их средства метапрограммирования сопоставимыми.

Здравствуйте, PhantomIvan, Вы писали:

PI> а можешь выписать что есть в Скале, чего нет в Немерле?

Можно. Но туташняя публика во сновном не поймет того о чем идет речь.

В скале есть две вещи которые мощьнее Немерла.
1. Более общая реализация алгеброических типов.
2. Не явные замыкания.

Здравствуйте, Gajdalager, Вы писали:

G>либа scala.actors — это реализация Erlang-модели паралелизма.. Т.е. на пальцах акторы — это механизм, который позволяет обмениваться сообщениями между потоками. Посмотри здесь и здесь

С каких пор библиотека стала приемуществом языка? Не уж то такую нельзя сделать на Немерле?
Потом ты бы поинтересовался о ее производительности.

Здравствуйте, eao197, Вы писали:

E>тем более, что я еще статью о Ruby RSDN-у должен

Ну, так занялся бы делом. А то сам позоришся и за одно анти пропагандой Руби занимаешся.

Здравствуйте, VladD2, Вы писали:

E>>тем более, что я еще статью о Ruby RSDN-у должен

VD>Ну, так занялся бы делом.

Не тебе мне указывать, чем заниматься.

Здравствуйте, FR, Вы писали:

FR>Тогда зачем ты предлагаешь мне его использовать для работы?

А я тебе это и не предлагал. С чего ты так решил?

Здравствуйте, eao197, Вы писали:

E>И некоторые фичи, которые при первом рассмотрении кажутся замечательными, на долгую перспективу уже таковыми не выглядят (в первую очередь макросы).

Я про это читал. "А вдруг мне захочется использовать разные макросы с одинаковыми названиями, да причем обязательно в пределах одного метода, чтобы места использования этих макросов нельзя было разнести по отдельным файлам"
Высосано из пальца.

E>Но вот сталкиваясь с такой навязчивой пропагандой лично я невольно вспоминаю житейскую мудрость: "Хороший товар в рекламе не нуждается".

Когда вокруг полно реакционеров — нуждается. Телеграф — уж казалось бы, такая штука, в полезности которой просто нельзя было сомневаться. Так нет — и его высмеивали, когда он только появился.

Здравствуйте, VladD2, Вы писали:

E>>a) почему в отношении ФВП Scala уступает Nemerle?

VD>Скала здесь была пропущена по случайности. Думаю, всем не предвязтым читателям это было очевидно хотя бы из заключительного слова.

Значит один из пунктов уже не корректен.

E>>b) до чего именно ООП в Ruby не дотягивает?

VD>Тем что он ниже плинтуса. Нет даже примитивной защиты.

Аргументация не выше того же плинтуса.

E>>c) почему в плане встроенной поддержки параллелизма не рассматриваются Actor-ы в Scala?

VD>В Скале нет встроенной поддержки параллелизма. Она выполнена в виде библиотеки и по признанию автора работает существенно медленее чем аналогичная а Эрлэнге. Как бы там ни было, но то что реализуется библиотекой не может являться приемуществом языка. Хотя в данном случае я отдал должное Эрлэнгу.

А разве Nemerle.Concurrency не является такой же библиотекой (макросов в данном случае)?

E>>d) почему расширяемость языка считается неоспоримым достоинством?

VD>Потому что нужно было внимательно читать приведенную в начале письма цитату. Расширяемый язык мощьнее не расширяемого просто потому, что он может впитывать остуствующие возможности. Замечательными примерами того являются макросы Late и Lazy привносящие в Немерле динамику и ленивые вычисления.

Видишь ли, мне фиолетово, внесены ли Late и Lazy в язык макросами или как-то еще.
Но позиция понятна -- ты считаешь, что каждый пользователь имеет право расширять язык так, как ему нужно.

Здравствуйте, FR, Вы писали:

FR>Объясни пожалуйста, чем более мощны функции в это тройке (Окамл Хаскель и Немерле) чем например в питоне (или руби).

Наличием карринга/частичного применения.

FR>Мне кажется что наоборот Окамл и Немерле немного уступают тут динамике (за счет того что в динамике функции более обобщенные).

Обобщенность не влияет на работу с функциями. К тому же у Немерле и темболее у Хаскеля с ОКамлом особых проблем с обобщением нет. В Немерле дела чуть хуже из-за особенностей системы типов .NET.

FR>Да на самом деле очень мощная возможность. Но во первых есть вещи частично перекрывающие эти возможности (мультиметоды) и во вторых на очень большем классе задач пользы от паттерн матчинга нет (зато есть класс задач где он на порядок увеличивает мощность языка). По моему ПМ очень мощное, но достаточно узко заточенное оружие.

На самом деле при правильном проектировании большинство задач получает выигрышь от паттерн-матчинга. В прочем я уже упоминал о том, что Грэхем ошибается выстраивая языки в прямую линию. Наличие паттерн-матчинга (и качество его реализации) это повышение мощьности в одном из направлений. Не спорю, что если тебе кажется более интересным другое направление, то и выводы будут другие.

FR>В питоне да есть свои заморочки, (но с другой стороны его ООП мощнее за счет метаклассов чем), но в чем Руби-то слабее?, по моему там ООП мощнее Скалы и Немерле (тоже за счет метаклассов).

Отсуствием защиты. В прочем я и отмечал Питон в этом смысле. В Руби дела отсбоят несколько лучше.

FR>Выделенное интенсивно делают, в рамках PyPy.

Вот только результат пока что слабенький.

FR>Ну руби позволяет и частично синтаксис "менять", питон нет, но метапрограммирование у обоих вполне на уровне. К тому же питон предоставляет библиотеки для полного доступа к AST и комиляции, и при желании там очень много можно наворотить.

Руби тоже не позволяет менять сам синтаксис. Он позволяет некоторым конструкциям прикидываться другими. Но это менее мещьный механизм. И более опасный (нет синтаксического контроля).

VD>>11. Встроенная поддержка параллелизма. Тут в списке остается только Эрлэнг. Но Немерле, ОКамл и Лисп позволяют добавить подобнрые фрэймворки в виде библиотеки. Так что пункт не столь очевиден.

FR>Питон тоже позволяет в виде библиотеки, есть даже несколько в стиле эрланга.

Собственно о том и речь. Но тут скорее говориться о введении в язык неких боле высокоуровневых контсрукций. В прочем возможно метастредств Питона и Руби хватит на это. Готов согласиться, что этот пункт можно решать библиотечными методами при некоторых условиях.

FR>Пока да, посмотрим что из PyPy получится.

Посмотрим. Хотя я в такие проекты не верю.

FR>Легко добавить пару пунктов и он точно также отсеется.
FR>(например компиляция в нативный код)

Весь код дотнета компилирюется в нэтив-код. Так что не надо. Да и мощьности языку это не предает. Так что фактически это опят разговор из серии "мне не нравится дотнет".

VD>>Конечно можно сказать, что кому-то некоторые пункты могут оказаться не важными, но факт отсается фактом.

FR>Не факт, а твое субъективное мнение.

Мнение вполне себе объективное. По сути ты не поспорил не с дним пунктом. Даже с твоими уточнениями ничего коренным образом не меняется.

Немерле объективно более мощьный язык. Просто, как я уже говорил, многомерность самого понятия мощьности делает осознание этого факта слжной задачей. Ведь если тебе не важны некоторые измерения, то ты вполне можешь говорить что Немерле имеет приблизительно одинаковую мощьность с другим языком (например, Руби или Питон). А учитывая эффект Блаб-программиста из которого вытекает, что некоторые измерения попросту отсутсвуют для тех людей которые с ними не знакомы, то любой Блаб-программист считает все остальные языки стольк же мощьными как и его любимый Блаб. И проистекает это потму, что он думает на этом самом Блабе. Так что единственный способ оценить другой язык — это серьезно на нем поработать. И практика показывает, что те кто поработал на том самом Немерле редко высказывают негативное мнение о нем. Собственно по этому я считаю, что любая, даже самая негативная, информация полезна для Немерле. Ведь она заставляет пытливые умы пробовать писать на этом языке. А значит рано или поздно они его оценят. Собсвтенно на нашем сайте процесс уже пошел. Я уже давно не провоцирую других на разговоре о языке. Этот разговор поднимается сам если речь хоть как-то касается мощности языка. Так что большое человеческое спасибо еао197 за его плодотворную работу!

AndreiF wrote:
> Небольшая поправочка. Немерле включает в себя практически все полезные
> идеи языков, который были до него.
Да ну....

1. Поддержка работы в автономном режиме, без какой-либо runtime-библиотеки.
2. You don't pay for what you don't use.
3. Возможность оптимизаций до уровня корпуса компьютера (в том числе
работа без GC).
4. Возможность системного программирования.
5. Широчайшая портабельность (в том числе, например, на архитектуры с
36-битными процессорами).

Вот что-то я в упор не вижу этих фич в Nemerle. А для меня многие из них
весьма значимы.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gajdalager, Вы писали:

G>>либа scala.actors — это реализация Erlang-модели паралелизма.. Т.е. на пальцах акторы — это механизм, который позволяет обмениваться сообщениями между потоками. Посмотри здесь и здесь

VD>С каких пор библиотека стала приемуществом языка? Не уж то такую нельзя сделать на Немерле?
VD>Потом ты бы поинтересовался о ее производительности.

Я и не говорил, что это преимущество языка Человек спросил, что такое scala.actors, я ответил. Кроме того, в твоем исходном сообщении записано:

11. Встроенная поддержка параллелизма. Тут в списке остается только Эрлэнг. Но Немерле, ОКамл и Лисп позволяют добавить подобнрые фрэймворки в виде библиотеки. Так что пункт не столь очевиден.

Т.е. очевидно, что пропущена(скорей всего, по недосмотру), Скала, которая не только позволяет, но и уже добавила подобный фреймворк

Здравствуйте, VladD2, Вы писали:

VD>Подробнее лучше у FR. Лично для меня ЯП не имеющий защиты членов. И оперирующий разными странными вещами вроде __хзч__ вряд ли может является приемлемой реализацией ООП. И то что ЯП можно подкрутить на метапрограммировании как-то не очень радует. Ведь есть языки которые не надо подкручивать. А подкручиваение это всегда тормоза (для скриптов) и выбрасывание своего времени.

Подкручивание в питоне реализованно так что тормозов не будет, метаклассы работают аналогично compile time для языков со статической типизацией.

VD>Ну, вот Немереле тоже не позволяет сделать это на 100%. Но я уверен, что его разумные пределы более широки и это более разумно. Причем надо учитывать, то что без информации о типах многое сделать не удается. А скриптовые метасредсва основанны на тексуальных движках. Плюс в них вообще не просто получить информацию о типах (она динамична). Это не позволяет реализовать некоторые задумки. А значит мы имеем место меенее мощьного решения.

В случае питона метаклассы и подобные вещи не имеют ничего общего с текстуальными макросами, и информация о типах и даже полная интроспекция в них вполне доступны.

VD>Не так. Проблема в том, что ты смотришь на языки с точки зрения менее мощьного языка. И от того тебе кажется, что что-то не важно, а что-то является всего лишь непонятным извращением. И до тех пор пока ты не освоищь более мощьный язык ты так и не будешь видеть все правды.

Проблема в том что реально измерить мощность языков очень тяжело, оценка во многом получается субъективной.

VD>Возвращаясь к разговору о многомерности в фичах могу сказать, что реально из приемуществ скриптов у нас остается только возможность менять типы на ходу (без остановки приложения). Это вряд ли серьезно поднимает мощьность языков. И в итоге даже если исходить из твоих позиций мы (точнее ты) имеем паритет. А раз так, то выбор в пользу языка с мощьной IDE, быстрым конечным кодом является очевидным. Так что на весах у нас явный прогресс против нежелания иметь дело с .NET. Возможно кому-то такое протиповопоставление кажется серьезным. Не спорю.

Мне кажется ты чуть выше очень правильно описал свое понимание динамики:

И от того тебе кажется, что что-то не важно, а что-то является всего лишь непонятным извращением.

Если оставить в стороне очень спорные разговоры о мощности, то динамика просто не пошла у тебя, ты ее не понимаешь и не хочешь понимать поэтому плюсы тебе кажутся очень мелкими а минусы очень большими.

PhantomIvan wrote:
> PA>Например, недетерминизм из Пролога/Mercury.
>
> а что это?
Множественность решений.

my_delete([X|Xs], X, Xs).
my_delete([Y|Ys], X, [Y|Ys1]) :- my_delete(Ys, X, Ys1).

Отношение my_delete(Xs, X, Ys) выполняется, если список Ys получен из Xs
удалением одного (любого) вхождения X. Некоторые запросы будут
возвращать множество решений:

?- my_delete([1,2,3,1,4,5,1], 1, Result).

Result = [2, 3, 1, 4, 5, 1] ;

Result = [1, 2, 3, 4, 5, 1] ;

Result = [1, 2, 3, 1, 4, 5] ;

No

?- my_delete([1,2,3], X, Y).

X = 1
Y = [2, 3] ;

X = 2
Y = [1, 3] ;

X = 3
Y = [1, 2] ;

No

Отношение my_add является обратным к my_delete:

my_add(Xs, X, Ys) :- my_delete(Ys, X, Xs).

Чтобы перетасовать список, нужно перетасовать его хвост, а затем голову
вставить в полученный список (в произвольную позицию):

shuffle([], []).
shuffle([X|Xs], Ys) :-
        shuffle(Xs, Xs1),
        my_add(Xs1, X, Ys).

Понятное дело, shuffle тоже может порождать множество решений.

Ну и напоследок — дурацкая реализация сортировки. Чтобы отсортировать
список, нужно, как известно, переставить элементы исходного списка таким
образом, чтобы получился упорядоченный список:

sorted([]).
sorted([_]).
sorted([X,Y|T]) :- X =< Y, sorted([Y|T]).

my_sort(Unsorted, Sorted) :-
        shuffle(Unsorted, Sorted),
        sorted(Sorted).

Вот такие пироги. Я это не к тому, что Пролог — это архикруто. А к тому,
что один язык, в котором реализованы все полезные идеи, —
это перочинный нож со встроенным холодильником.

Здравствуйте, AndreiF, Вы писали:

E>>И некоторые фичи, которые при первом рассмотрении кажутся замечательными, на долгую перспективу уже таковыми не выглядят (в первую очередь макросы).

AF>Я про это читал. "А вдруг мне захочется использовать разные макросы с одинаковыми названиями, да причем обязательно в пределах одного метода, чтобы места использования этих макросов нельзя было разнести по отдельным файлам"
AF>Высосано из пальца.

Дай бог, чтобы так и было. Чтобы какой-нибудь умелец не захотел сделать более продвинутый Nemerle.Concurency.async, чем в стандартной библиотеке.

E>>Но вот сталкиваясь с такой навязчивой пропагандой лично я невольно вспоминаю житейскую мудрость: "Хороший товар в рекламе не нуждается".

AF>Когда вокруг полно реакционеров — нуждается. Телеграф — уж казалось бы, такая штука, в полезности которой просто нельзя было сомневаться. Так нет — и его высмеивали, когда он только появился.

А ты вообще-то про какой именно телеграф говоришь? Их же разные модели существовали.

Кстати, революционерам не мешало бы помнить, что "Революция пожирает своих детей".

И еще цитата в тему:

Пытаясь исследовать перемены, вы порой выслушиваете весьма разнообразные мнения. Джерри Джонсон из Института бизнеса Меннингера, предположил, что это разнообразие следует определенному шаблону, который он назвал "Спектром сопротивляемости переменам":

1. Слепая преданность (никаких вопросов)
2. Верить, но оспаривать
 а. Скептицизм ("Покажите")
 б. Пассивное наблюдение ("Какая мне польза от этого?")
 в. Оппозиция (Боязнь изменений)
 г. Оппозиция (Боязнь утраты власти)
3. Активное противодействие.

В этом спектре есть место для каждого человека, и определяется оно тем, как человек реагирует на перемены.

Взгляните на этот спектр и спросите себя, кто из этих людей -- ваши потенциальные враги, а кто -- возможные союзники? Очевидно, активно противодействующие опасны, они будут искать способы вернуться к прежнему состоянию любой ценой. Вы можете заключить, что слепо преданные -- хорошие ребята, а остальные просто нытики, и что слепо преданные станут союзниками, а остальных можно записать во враги.

Джерри указывает, что подобный взгляд неверен. Так, мы должны осознавать опасность, которую представляют слепо преданные. Они, вероятно, достаточно безобидны и готовы следовать за любой модной идеей. Или правит мода момента: "Надо перестать использовать этот бухгалтерский пакет, мы и сами не хуже можем сделать системку на базе интранет-сети с применением Java Без Кофеина. Стоп. Не надо без кофеина. Я только что видел на сайте Computing This Nanosecond рекламу Double-Java latte с пенистыми апплетами". Их поддержка улетучится столь же быстро, как появилась, потому что иначе они не смогут следовать за новой модой.

Джонсон утверждает, что верующие, но способные оспорить -- единственные разумные союзники любых перемен. Две крайности -- слепо преданные и активно противодействующие -- настоящие враги. Успех перемен будет зависеть от того, как вы сумеете справиться с верующими, способными подвергать перемены сомнению.

(ДеМарко и Листер, Peopleware, 2-е издание)

Так вот, наиболее горластые пропагандисты Nemerle явно относятся к слепо верующим. И это вызывает раздражение. Ведь тот же Влад сам заявлял, что слиняет с Nemerle на что-нибудь более крутое, как только оно появится. Между тем, многим, выбравшим Nemerle в качестве инструмента придется сидеть на нем достаточно долго. Вспоминая COBOL можно предположить, что долго может растянуться на годы.

Еще больше, однако, раздражает то, что слепо верующие автоматически записывают всех остальных в категорию активно противодействующих. Хотя подавляющее большинство из нас как раз сомневающиеся (скептики и наблюдатели). Например, я лично уже давно перестал обсуждать технические особенности Nemerle -- ну есть такой язык, ну вот такой он, ну вот не нужен он мне (пока?). Есть да и есть. А вот кипишь вокруг него -- это совсем другое дело.

Здравствуйте, AndreiF, Вы писали:

AF>Здравствуйте, FR, Вы писали:

FR>>Тогда зачем ты предлагаешь мне его использовать для работы?

AF>А я тебе это и не предлагал. С чего ты так решил?

С того что разговор шел про это пока ты не влез.