to better prepare students for graduate school or real-world design challenges

Смейтесь, разрази вас гром, смейтесь! Через час вы будете смеяться по-иному. А те из вас, кто останется в живых, позавидуют мертвым!

Р.Л. Стивенсон, «Остров сокровищ»

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

to better prepare students for graduate school or real-world design challenges

PI>не самые глупые люди, не так ли?

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

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

ЗХ>Я упоминал "светлую голову"

Но суть в другом, в том, что сейчас для сторонников Scala/Nemerle "золотой век" -- их окружают не только единомышленники, но люди с аналогичными способностями и желанием изучать, и применять что-то новое. Поэтому и кажется, что все вокруг так замечательно и решения сложных задач совместными усилиями находится элементарно. Но на подходе мы, скептики и консерваторы. Для которых новый язык это всего лишь лишние заморочки по переходу на новый инструмент. И которым преимущества хвостовой рекурсии придется объяснять так же долго и муторно (и не один раз), как когда-то приходилось доказывать преимущества наследования и полиморфизма (а потом много бить по рукам за их доведенное до маразма использование). Так что готовтесь, господа, легкой жизни не будет.

Пишу длинно, поскольку нет времени писать коротко.

ЗХ>По мне, так связано. И Декарт это подтверждает

Но сражаясь за красоту
Дурни подняли пыль

Ну, как вы наверняка заметили, мы не слишком быстро реализуем новые возможности и исправляем ошибки.
...
Я думаю, теперь пора стабилизировать сам язык и сосредоточиться на:
— исправлении ошибок
— улучшении в API компилятора/макросов
— улучшении производительности
— ну и конечно на вашем замечательном проекте интеграции

Продвижение в этой области + возможно еще некоторое улучшение в документации / тьюториалах, по моему мнению, — хороший план развития для Nemerle.
Проблема в том, что у меня и Михал не так-то много времени для этого, учитывая, что (особенно для Михала) это не очень "интересная" работа...

One problem is that few developers are motivated to work on bugs

АХ>Ты теплое с мягким не путай. Ошибки в языке — это ошибки дизайна. Их обычно исправляют в течение нескольких лет, а как правило вообще не исправляют, а просто другой язык придумывают .

Well, as you probably noticed our support for implementing features and fixing bugs is not very fast.

Парадокс Блаба
Что же в Lisp'е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.
И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
Я начну с шокирующего утверждения: языки программирования отличаются друг от друга своей мощностью.
По крайней мере мало кто будет спорить, что высокоуровневые языки более мощные, чем машинный язык (машинный код и ассемблеры – VladD2). Большинство программистов согласятся, что, как правило, программировать стоит не на машинном языке, а на каком-нибудь языке высокого уровня, переводя программу в машинный код с помощью компилятора. Сейчас эта идея получила даже аппаратное воплощение — с восьмидесятых годов команды процессоров разрабатываются скорее для компиляторов, чем для программистов.
Каждый знает, что писать всю программу вручную на машинном языке — ошибочно. Но гораздо реже понимают то, что существует и более общий принцип: при наличии выбора из нескольких языков ошибочно программировать на чем-то, кроме самого мощного, если на выбор не влияют другие причины (VladD2: выделено мой, мне кажется эта мысль очень важна, ведь если, например, более мощный язык не обеспечивает приемлемой производительности, то его выбор так же будет не оправданным).
Все языки одинаково мощные, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.
Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, что нельзя исправить написанием библиотечных функций (VladD2: в прочем бывает так, что средствами языка B в принципе можно решить проблему, решение ее столь сложно, что решение это можно назвать чисто теоретическим).
Есть много исключений из этого правила. Если вы пишете программу, которая должна тесно взаимодействовать с программой, написанной на определенном языке, возможно, окажется разумным писать новую программу на том же языке.
Если вы пишете программу, которая должна делать что-то очень простое, вроде численной обработки больших массивов данных или манипуляций с битами, можно использовать язык не самого высокого уровня абстракции, тем более что программа будет слегка быстрее (VladD2: и то не факт).
Если вы пишете короткую программу, которую используете один раз и выбросите прочь, возможно, следует использовать тот язык, который имеет лучшие библиотечные функции для данной задачи.
Но в целом для программного обеспечения нужно использовать самый мощный (и приемлемо эффективный) язык из всех доступных. Отличный от этого выбор — это ошибка такого же рода, как программирование в машинных кодах, хотя и с меньшими негативными последствиями.
Понятно, что уровень машинного языка очень низок. А высокоуровневые языки часто рассматриваются как одинаковые, по-крайней мере, так принято считать. Но это не так. Технический термин "язык программирования высокого уровня" не обозначает ничего определенного. Не существует четкой границы между множеством "машинных" языков с одной стороны, и множеством "высокоуровневых" с другой. Языки распределены в континууме (возможно, не просто континуум, а некая структура, уменьшающаяся кверху;
важна здесь не форма, а сама идея о том, что существует, по крайней мере, частичный порядок) абстрактности, начиная от самых мощных "языков высокого уровня" вниз к "машинным языкам", которые, в свою очередь, тоже отличаются друг от друга по мощности.
Возьмем Cobol. Cobol — язык высокого уровня, так как компилируется в машинный язык. Но станет ли кто-нибудь утверждать, что по мощности Cobol эквивалентен, скажем, Python-у? (VladD2: учитывая свой опыт общения на форумах RSDN скажу, что несомненно скажет ) Возможно, он ближе к машинному языку, чем Python.
А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык.
Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли.
Программисты очень привязываются к своим любимым языкам, а я не хочу оскорбить ничьи чувства, поэтому я объясню свою позицию, используя гипотетический язык с названием Блаб.
Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык.
И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol-а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol-е ведь даже нет возможности X, присутствующей в Блабе!
Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе (выделено мной – VladD2).
Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. «Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!»
Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел ввиду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Я знаю это из своего опыта, когда учился в старших классах школы и писал программы на Бейсике. Этот язык не поддерживал даже рекурсию. Трудно представить написание программ без рекурсии, но в то время мне это было не нужно. Я думал на Бейсике. Я был спец. Мастер всего, что изучил.
Пять языков, которые советует хакерам Эрик Реймонд, находятся в разных точках континуума мощности, и то, где они находятся относительно друг друга, — тонкий вопрос. Я скажу, что Lisp находится на вершине континуума. И чтобы поддержать это утверждение, я скажу о том, чего мне не хватает, когда я смотрю на остальные пять языков. Как же можно что-то сделать с ними, думаю я, без свойства Z? И самое большое Z — это макросы. (Рассматривать макросы как отдельное свойство — это немного неправильно. На практике их польза увеличивается такими свойствами Lisp'а, как лексические замыкания и частичная параметризация (rest parameters) – аналогичная возможность в Nemerle назевается «частично применение (partial application) – VladD2».
Во многих языках есть что-то, называющееся макросом. Но макросы в Lisp'е уникальны (на сегодня это так только если глядеть на другие языка с высоты Lisp-а, но об этом позже – VladD2). То, что делают макросы имеет отношение, верите вы или нет, к скобкам. Создатели Lisp'а добавили все эти скобки в язык не для того, чтобы отличаться от других. Скобки в Lisp'е имеют особый смысл, они — внешнее свидетельство фундаментальной разницы между Lisp'ом и другими языками.
Программа на Lisp'е состоит из данных. И не в том тривиальном значении, что исходные файлы содержат символы, а строки — один из типов данных, поддерживаемых языком. После прочтения программы парсером Lisp код состоит из готового к использованию дерева структур данных.
Дело не в том, что в Lisp'е странный синтаксис, скорее, его нет вообще. Программы пишутся в готовых синтаксических деревьях, которые в других языках генерируются парсером во время разбора исходного текста. Эти синтаксические деревья в Lisp'е полностью доступны вашим программам, и вы можете писать программы, которые изменяют эти деревья. В Lisp'е подобные программы называются макросы. Это программы, которые пишут программы.
Программы, которые пишут программы? И когда же такое может понадобиться?
Не очень часто, если вы думаете на Cobol'е. И постоянно, если вы думаете на Lisp'е. Было бы удобно, если бы я дал пример мощного макроса и сказал бы: "Вот! Смотрите!". Но если бы я и привел пример, для того, кто не знает Lisp, он выглядел бы не более чем белиберда. Рамки данной статьи не позволяют изложить все необходимое для понимания подобного примера. В книге Ansi Common Lisp я старался излагать материал как можно быстрее, но даже так я не добрался до макросов раньше страницы 160.
Однако мне кажется, что я могу дать убедительный аргумент. Исходный текст редактора Viaweb на 20-25 процентов состоял из макросов. Макросы сложнее писать, чем обычные функции Lisp'а, и считается дурным тоном использовать их там, где можно без них обойтись. Поэтому каждый макрос в той программе был необходим. Это значит, что примерно 20-25 процентов кода в программе делают то, что нельзя просто сделать на других языках.
Как бы скептически ни относился Блаб-программист к моим заявлениям о таинственной мощи Lisp'а, это должно его заинтересовать. Мы не писали этот код для своего собственного развлечения. Мы были маленькой компанией, и программировали так, как только могли, чтобы возвести технологический барьер между нами и нашими конкурентами.
Пытливый читатель может задаться вопросом, а нет ли здесь взаимосвязи? Некоторая большая часть кода делала нечто, что очень сложно сделать на других языках. Получившееся в результате программное обеспечение делало то, что программное обеспечение наших соперников делать не могло. Возможно, между этими фактами есть связь. Я советую вам подумать в этом направлении. Возможно, это все не просто старческие бредни.

ЗХ>

Кстати, прежде чем продолжить хочу заметить, что эту тему превратил в тему "Казалось бы причем тут Немерле?" не я, и даже не Вольфхаунд. Так что не надо с больной головы на здоровую (это я нашим уважаемым аксокалам, стрпер все же как то не красиво ). Если чесно, то я уже переболел стадией восхищения и неуверенности. Моя позиция по поводу этого языка полностью сформировалась. Он и Скала это будущее мэйнстрима и все кто ждет стада чтобы последовать за ним, не всилах преодолеть свои привычки или кому просто не нравится дотнет или ява меня попросту не интересуют. Так что просьба воспринимать мой ответ исклчительно как мое мнение, а не предложение поспорить.

VD>Ну, на конец-то вы заговорили о чем-то интресном. Пофлэйммим...

ЗХ>>

#это воспроизведение кусочка вашего спора с Мамутом 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

void Login(User user)

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

ЗХ>#это воспроизведение кусочка вашего спора с Мамутом 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();
  }
}

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))))