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

FR>В питоне та же оптимизация тоже очень легко делается.

Языком. Так как пред тем как заморозить нужно еще посчитать. У Немерла есть отличный компилятор и время компиляции. А что есть у Питона?

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

VD>>Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.

E>Какой изящный переход на личности

Ага. Какая подлость осбуждение личности твоего сервера.

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

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

FR>>В питоне та же оптимизация тоже очень легко делается.

VD>Языком. Так как пред тем как заморозить нужно еще посчитать. У Немерла есть отличный компилятор и время компиляции. А что есть у Питона?

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

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


FR>>Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение

VD>А что и кого обошло? GCC слил? VC6 тоже сольет. У Vermicious Knid вот и VC на машине сливает. Твоеи любимые языки сольют так что мама не горюй. Так чем ты тут пыташся подколоть?

Я ничем, это тут у вас война со всем миром.
Я думаю Vermicious Knid просто ошибся.

VD>Вопрос повышения качества оптимизации управляемых сред — это вопрос времени.

Угу и возможно бесконечно большого

FR>>Ну и что, я его для такой дурости не использую

VD>Действительно! Не программировать же на нем? Так скриптики не критичные писать, чтобы время потянуть.

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

FR>>Да и не так и лег если на нем оказалось несложно повторить без всяких макросов легендарный и всемогущий Memoize

VD>Да, лег, лег. (3, 12) не выполнится вообще.

Угу а N лег на 3, 13 а VC8 спокойно вычислил 3, 14

VD>>>В общем, получается забавная ситуация. Вы сравниваете Немерле с каким-то мифическим языком краткойть которого как у Руби, а скорость как у С++. Но помилуйте, таким средством является только Немерле. С++ запутан, сложен, неуклюж и опасен. Даже статическая типизация не спасает от моря проблем. Руби медленен и требует больше отладки и тестирования в следствии отсуствия статической типизации.

FR>>А почему бы и не сравнивать если я как раз и использую связку python + С++.

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

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

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

VD>>>Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.

E>>Какой изящный переход на личности

VD>Ага. Какая подлость осбуждение личности твоего сервера.

Видишь ли, такой вещи, как "мой сервер приложений" нет в природе.

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

FR>Я думаю Vermicious Knid просто ошибся.
Нет, я не ошибся. Повторяю еще раз. На некоторых(слабых) процессорах оптимизация раскрытием рекурсии делает код на C++ медленнее кода на Nemerle, и довольно заметно сильно. При этом без нее тот же код на C++ слегка опережает Nemerle.

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

Я такое наблюдал однажды когда писал один небольшой парсер на C++. Для его оптимизации я активно юзал как раз раскрытие рекурсивных функций. После очередной совсем небольшой и незначительной доработки я вдруг получил резкое падение производительности. От раскрытия рекурсии естественно пришлось отказаться, так как падение производительности было более сильным, чем в случае отказа от этой оптимизации.

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

И тут важно не то, что Nemerle идет почти наравне с C++, а то что он опережает C#. На C++ мне уже как-то вообще наплевать, он меня мало интересует.

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

На самом деле все еще только начинается. Если победа будет не за Nemerle, то в любом случае за управляемыми языками. И случится это еще при нашей жизни. У C++ останется только совсем крохотная ниша.

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

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

A>>Мне всегда хотелось узнать, какие претензии программисты на C# имеют к boost::function. Спасибо за исчерпывающий список.

VD>На С++ я программировал 13 лет. На C# 4 года. Так что это еще большой вопрос кто из нас на чем программист. И кстати, boost::function появился уже тогда когда С++ стал становиться мне менее и менее интересен.

Неважно сколько ты лет программировал на C++. С boost::function ты явно не знаком.

VD>Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями.

Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.

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

A>Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.
А что с ним знакомиться? Замыканий в С++ всеравно нет.

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

A>Неважно сколько ты лет программировал на C++. С boost::function ты явно не знаком.

Интересный вывод. А теперь сделай поиск по этому сайту.
Просто я кроме того знаком и с прямыми решенияи.

VD>>Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями.

A>Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.

Серьезно? Ну, давай передай сслку на метод в другую ДЛЛ не используя описание в виде исходников.

Я уже не говорю о супер синтаксисе все эти _1, _2... и:

f = (&var ->* &someclass::foo);

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

Сравни ради хохмы свой пример с немерлом:

foo(_ : int) : void {}
bar(_ : char) : void {}
// бред пропускаем struct functor : std::unary_function<int, void> {...};
class someclass { foo(_ : int) : void {} };

// straight forward call
mutable f = foo;
f(1); // -> foo(1)

// parameter types don't have to match
f = bar;
f(2); // до этой строчки не дойдет. :)

// lambda tricks - здесь не лямбд, ни трюков не нужно! Функция ведь первокласный объект в языке. :)
f = Console.Write;
f(10); // -> Console.Write(10)

// functors - идут в лес как левый рудимент. :(
//f = functor();
//f(10); // -> functor().operator(10);

// member functions
def var = someclass();
f = var.foo;
f(10); // -> var.foo(10)

Но это в общем-то детство. А вот так уже куда интереснее.

def add = _ + _; // частичное применение. Преобразуем оператор в функцию с двумя параметрами. 
WriteLine(add(1, 2)); // выводит 3

def inc = add(_, 1); // частичное применение фукнции полученной в результате аналогичного процесса :)
WriteLine(inc(3)); // выводит 4

// Локальная функция с замыканием на лексический контекст. 
// Функция Add5AndInc исползует функции inc и add объявленные в локальном контексте.
def Add5AndInc(x) { inc(add(x, 5)) }
WriteLine(2)  // выведет "8"
...

class Test
{
    // метод возвращающий функцию принимающую int и возвращающую string.
    public Method1(prefix : string) : int -> string
    {
        x => $"$prefix: $x" // в качестве фукнции возвращаем настоящую лябду ссылающуюся на лексический контекст.
    }
}
...
def test = Test();

def f1 = test.Method1("prefix 1");
def f2 = test.Method1("prefix 2");
WriteLine(f1(5));  // выведет "prefix 1: 5"
WriteLine(f2(5));  // выведет "prefix 2: 5"
WriteLine(f1(10)); // выведет "prefix 1: 10"

Все это не требует левых библиотек для компиляции. Компилируется в мгновении ока. Быстро работает. Не приводит к необъяснимым сообщениям об ошибках при опечатках.

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

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

A>>Неважно сколько ты лет программировал на C++. С boost::function ты явно не знаком.

VD>Интересный вывод. А теперь сделай поиск по этому сайту.
VD>Просто я кроме того знаком и с прямыми решенияи.

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

VD>>>Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями.

A>>Опять промах! Извени, но те "проблемы", которые ты "нашёл" в boost::function, существуют лишь в твоём воображении.

VD>Серьезно? Ну, давай передай сслку на метод в другую ДЛЛ не используя описание в виде исходников.

Передам. В чём проблема?

VD>Я уже не говорю о супер синтаксисе все эти _1, _2... и:
VD>

VD>f = (&var ->* &someclass::foo);
VD>

VD>колдовство на марше да и только.

VD>Сравни ради хохмы свой пример с немерлом:

При чём здесь Nemerle? Если ты не в состоянии запомнить о чём идет речь в этой ветке, напомню, что мы обсуждаем свойства и делегаты применительно к C++.

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

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

FR>>Я думаю Vermicious Knid просто ошибся.
VK>Нет, я не ошибся. Повторяю еще раз. На некоторых(слабых) процессорах оптимизация раскрытием рекурсии делает код на C++ медленнее кода на Nemerle, и довольно заметно сильно. При этом без нее тот же код на C++ слегка опережает Nemerle.

На каком именно процессоре и точные цифры можешь привести? а также код и ключи с которыми компилировалось?

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

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

VK>Я такое наблюдал однажды когда писал один небольшой парсер на C++. Для его оптимизации я активно юзал как раз раскрытие рекурсивных функций. После очередной совсем небольшой и незначительной доработки я вдруг получил резкое падение производительности. От раскрытия рекурсии естественно пришлось отказаться, так как падение производительности было более сильным, чем в случае отказа от этой оптимизации.

FR>>Ну конечно самая важная задача в программировании это вычисление функции Аккермана, ты мне просто глаза раскрыл, большое спасибо
VK>Конечно функия Аккермана не самая полезная рекурсивная функция. Но по таким бенчмаркам можно косвенно судить о том как поведут себя различные рекурсивные обходы деревьев, парсинг и тому подобные алгоритмы.

По таким тестам мало о чем можно судить, так как для реальные функции не сводятся в основном к вызовам, они еще рабочее тело имеют

VK>И тут важно не то, что Nemerle идет почти наравне с C++, а то что он опережает C#. На C++ мне уже как-то вообще наплевать, он меня мало интересует.

Ну а мне наплевать на C#

VK>Правда я считаю, что никакая низкоуровневая оптимизация компилятором и предварительная оптимизация человеком не сможет заменить целевую оптимизацию основанную на профилинге живого приложения. Но раз уж эти тесты кто-то широко использует, то почему бы и не сравнить. Тем более что Nemerle, версия 0.1 которого появилась всего два года тому назад, и в котором пока практически отсутствует оптимизация как таковая, уже сейчас показывает на этих тестах производительность сравнимую с C++.

Угу только не забудь что очень большой процент этой производительности заслуга разработчиков NET, и поэтому оптимизация в N очень даже присутствует. Так что сравнивать надо не N vs C++ а NET + N vs C++.

VK>На самом деле все еще только начинается. Если победа будет не за Nemerle, то в любом случае за управляемыми языками. И случится это еще при нашей жизни. У C++ останется только совсем крохотная ниша.

Я бы так не надеялся вполне возможно проиграют обе стороны

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

FR>На каком именно процессоре и точные цифры можешь привести? а также код и ключи с которыми компилировалось?
Ты мне не веришь? Процессор Celeron, архитектуры P3. Код твой, с прагмой inline_recursion(on), ключ /Ox. На P4/K8 этот же код естественно выигрывает с большим отрывом.

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

FR>Если рекурсивная функция сложнее аккермана, есть очень большая вероятность что цена вызова не будет играть большой роли и будут иметь значение совсем другие оптимизации.
FR>По таким тестам мало о чем можно судить, так как для реальные функции не сводятся в основном к вызовам, они еще рабочее тело имеют
Я тебе уже привел пример функции сложнее аккермана, когда эта оптимизация приносила существенное увеличение производительности, но только до тех пор пока совокупный размер раскрываемого кода не превысил определенный порог. Для определенных процессоров даже функция аккермана с такой оптимизацией может вызвать проблемы.

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

FR>Ну а мне наплевать на C#
Ну а мне наплевать на сравнение производительности C++ и Nemerle, сравнение Питона и Nemerle, и так далее. Это вообще не важно. Nemerle не претендует на нишу этих языков. Его конкуренты это C#, Java и тому подобные языки.

Из этого можно сделать один вывод — ты пока не являешься потенциальным пользователем Nemerle. Я скажем года три-четыре назад тоже не являлся. Для меня основными и главными преимуществами моего любимого на тот момент языка программирования были шаблоны и возможность добиться максимально возможной производительности и эффективности. Что за язык я думаю ты догадаешься с первой попытки.

Я правда никогда особо не увлекался динамическими языками вроде Питона. Как выясняется наличие таких языков почему-то может служить оправданием недостатков C++ и аргументом против Nemerle/C# у программистов на C++.

FR>Я бы так не надеялся вполне возможно проиграют обе стороны
Проиграют кому/чему?

Динамическим языкам? Ну во-первых это все таки тоже управляемые языки. Но я бы на победу динамических языков все равно бы не надеялся. Было время когда динамические языки вообще были самыми лучшими и продвинутыми языками. Я имею в виду Common Lisp и Smalltalk. Когда эти языки появились они были на острие технологий, они предлагали действительно новые и революционные на тот момент концепции. Закончилось это все многочисленными пародиями, аналогами и вариациями, которые с каждым годом все плодятся и конца этому процессу не видно. А пока самые продвинутые из популярных Руби с Питоном вместе пока не могут сравниться по популярности даже с JavaScript. Но если это все таки случится и динамическим языкам проиграет Java/C#, то это все равно будет победа управляемых сред.

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

Нативному функциональному языку? Haskell? OCaml? Подобным языкам пророчат победу уже много лет. Но что-то никакого прогресса не видно. Единственное что видно — таких же ярых фанатов как у C++, абсолютно уверенных в непогрешимости и тотальном превосходстве Функциональной парадигмы.

Все остальное что приходит на ум это управляемые около-функциональные языки. Во-первых для CLR/JVM. Во-вторых для собственных управляемых сред, например Erlang.

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

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

FR>>На каком именно процессоре и точные цифры можешь привести? а также код и ключи с которыми компилировалось?
VK>Ты мне не веришь? Процессор Celeron, архитектуры P3. Код твой, с прагмой inline_recursion(on), ключ /Ox. На P4/K8 этот же код естественно выигрывает с большим отрывом.

Сейчас уже нет , но я ни в чем ни обвиняю, с этими тестами очень легко что-то перепутать, сам не раз попадался.
Просто тот же p3 Celeron недавно был моей основной целевой платформой и я много что на нем тестировал.

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

Может и к замедлению если функция перестанет лезть в кеш, но это не тот случай тут код получается много меньше 128Kb.

FR>>Если рекурсивная функция сложнее аккермана, есть очень большая вероятность что цена вызова не будет играть большой роли и будут иметь значение совсем другие оптимизации.
FR>>По таким тестам мало о чем можно судить, так как для реальные функции не сводятся в основном к вызовам, они еще рабочее тело имеют
VK>Я тебе уже привел пример функции сложнее аккермана, когда эта оптимизация приносила существенное увеличение производительности, но только до тех пор пока совокупный размер раскрываемого кода не превысил определенный порог. Для определенных процессоров даже функция аккермана с такой оптимизацией может вызвать проблемы.

Извини я не могу делать какие-то выводы на умозрительных примерах.

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

Решающим может быть размер кеша, так же может повлиять предсказатель переходов, но это уже для P4. Для P3 сильное замедление может быть из-за непоследовательного обращения к большим объемам данных в памяти.

FR>>Ну а мне наплевать на C#
VK>Ну а мне наплевать на сравнение производительности C++ и Nemerle, сравнение Питона и Nemerle, и так далее. Это вообще не важно. Nemerle не претендует на нишу этих языков. Его конкуренты это C#, Java и тому подобные языки.

Классно всем на все наплевать, но все равно сравниваем

VK>Из этого можно сделать один вывод — ты пока не являешься потенциальным пользователем Nemerle. Я скажем года три-четыре назад тоже не являлся. Для меня основными и главными преимуществами моего любимого на тот момент языка программирования были шаблоны и возможность добиться максимально возможной производительности и эффективности. Что за язык я думаю ты догадаешься с первой попытки.

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

VK>Я правда никогда особо не увлекался динамическими языками вроде Питона. Как выясняется наличие таких языков почему-то может служить оправданием недостатков C++ и аргументом против Nemerle/C# у программистов на C++.

Вот дурдом. Питон для меня не оправдание а рабочий инструмент.

FR>>Я бы так не надеялся вполне возможно проиграют обе стороны
VK>Проиграют кому/чему?

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

VK>Динамическим языкам? Ну во-первых это все таки тоже управляемые языки. Но я бы на победу динамических языков все равно бы не надеялся. Было время когда динамические языки вообще были самыми лучшими и продвинутыми языками. Я имею в виду Common Lisp и Smalltalk. Когда эти языки появились они были на острие технологий, они предлагали действительно новые и революционные на тот момент концепции. Закончилось это все многочисленными пародиями, аналогами и вариациями, которые с каждым годом все плодятся и конца этому процессу не видно. А пока самые продвинутые из популярных Руби с Питоном вместе пока не могут сравниться по популярности даже с JavaScript. Но если это все таки случится и динамическим языкам проиграет Java/C#, то это все равно будет победа управляемых сред.

Как ты думаешь что победит сверло или стамеска? А может кувалда всех уделает? Хотя вряд-ли, настоящие пацаны все делают только топором и без единого гвоздя
Я думаю будут нужны разные инструменты. А популярность вещь относительная, убери использование в браузерах и что останется от популярности JavaScript? Да мне в общем и не важна популярность.

VK>Другому неуправляемому низкоуровневому языку? D? Другому аналогу C++? Все это очень сомнительно. К D я честно говоря до сих пор питаю некоторые симпатии, но в его победу я практически не верю. По-моему беда D это недостаточная открытость. Он разрабатывается уже черти сколько лет и его судьба остается весьма туманна. Скорее я поверю в то, что новая ревизия стандарта C++ будет очень хороша и позволит языку вернуть потерянные позиции с лихвой.

Здесь согласен

VK>Нативному функциональному языку? Haskell? OCaml? Подобным языкам пророчат победу уже много лет. Но что-то никакого прогресса не видно. Единственное что видно — таких же ярых фанатов как у C++, абсолютно уверенных в непогрешимости и тотальном превосходстве Функциональной парадигмы.

У N тоже самое наблюдается

VK>Все остальное что приходит на ум это управляемые около-функциональные языки. Во-первых для CLR/JVM. Во-вторых для собственных управляемых сред, например Erlang.

Тебе 3 года назад N на ум пришел бы?

IT wrote:

> LCR>Потому что синтаксический сахар /does matter/.
> В данном случае мы столкнулись с феноменом непонимания этого простого
> факта. Видимо этот феномен витает и в комитете стандартизации C++
Если пихать всё, получится perl 6.
Вот мне не нравится ; ставить в конце каждой строки. А зачем? Вот javascript рулит. И что теперь? Почему эти
стандартизаторы c#/java и даже немерла такие косные, что не понимают что мне нравится?

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

FR>Сейчас уже нет
Да ради бога. Убеждать тебя в чем-то или доказывать что-то у меня нет ни малейшего желания. Я все равно не обладаю даром убеждения.

FR>Извини я не могу делать какие-то выводы на умозрительных примерах.
Это был не умозрительный пример, это пример из моей практики. Это было давно, но я это помню довольно отчетливо.

FR>Классно всем на все наплевать, но все равно сравниваем
Я уже не сравниваю. А вот ты был тем самым человеком которому показалась, что стоит продолжить сравнивание, так как у твоего любимого C++ не было безоговорочной победы.

FR>Откуда ты знаешь может я не недозрел, а перезрел?
А я не знаю, более того я не говорил например, что ты недозрел. Но раз уж ты сам так выразился, значит точно либо недозрел, либо перезрел.

FR>Я вообще тут с ужасом обнаружил что мне станвится все интересней и интересней написать что-то серьезное на лиспе
Ну и? У меня тоже был такой этап в жизни. Мне вообще на очень многих языках было интересно что-то написать и часто я пробовал это делать.

VK>>Скорее я поверю в то, что новая ревизия стандарта C++ будет очень хороша и позволит языку вернуть потерянные позиции с лихвой.
FR>Здесь согласен
Это была всего лишь метафора. В смысле скорее рак на горе свистнет(ревизия стандарта C++ будет очень хороша). То есть этого не будет.

FR>У N тоже самое наблюдается
Может у N тоже самое и наблюдается, а у вот у Nemerle не наблюдается. Что такое N вообще? Я о таком не слышал.
Шутка конечно, просто я не люблю такие сокращения и меня это немного раздражает.

FR>Тебе 3 года назад N на ум пришел бы?
Нет не пришел бы, и не прийдет сейчас. А Nemerle три года назад просто не существовало. Но уже были языки, которые во-многом были похожи на Nemerle и мне нравились уже тогда, например OCaml, Scala.

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

А вот Nemerle меня привлекает совсем не новизной и оригинальностью(тем более что я знаком с ним с выхода самой первой версии), а именно как практический инструмент для разработки на .NET. Тем более что он действительно на порядок лучше всего того, что есть для этой платформы.

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

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

FR>>Сейчас уже нет
VK>Да ради бога. Убеждать тебя в чем-то или доказывать что-то у меня нет ни малейшего желания. Я все равно не обладаю даром убеждения.

Это вещи в которых убедить меня не реально, только результаты и методики тестов и профайлер в зубы

FR>>Извини я не могу делать какие-то выводы на умозрительных примерах.
VK>Это был не умозрительный пример, это пример из моей практики. Это было давно, но я это помню довольно отчетливо.

Бывает
Но причина тормозов могла быть совсем в другом, как уже говорил эта не та область где авторитетны примеры из жизни.

FR>>Классно всем на все наплевать, но все равно сравниваем
VK>Я уже не сравниваю. А вот ты был тем самым человеком которому показалась, что стоит продолжить сравнивание, так как у твоего любимого C++ не было безоговорочной победы.

Если бы Влад не любил безапеляционно кричать слова типа "слил" ничего бы не было
Ну у него работа такая, надо же форум поактивнее делать

FR>>Я вообще тут с ужасом обнаружил что мне станвится все интересней и интересней написать что-то серьезное на лиспе
VK>Ну и? У меня тоже был такой этап в жизни. Мне вообще на очень многих языках было интересно что-то написать и часто я пробовал это делать.

Ну у меня тоже, просто я всегда думал что лисп не для меня

VK>>>Скорее я поверю в то, что новая ревизия стандарта C++ будет очень хороша и позволит языку вернуть потерянные позиции с лихвой.
FR>>Здесь согласен
VK> Это была всего лишь метафора. В смысле скорее рак на горе свистнет(ревизия стандарта C++ будет очень хороша). То есть этого не будет.

Вообще-то я был согласен с тем что как мне ни симпатичен D ему мало что светит.
А с C++ похоже все-таки что ты тоже прав, хотя поживем — увидим.

FR>>У N тоже самое наблюдается
VK>Может у N тоже самое и наблюдается, а у вот у Nemerle не наблюдается. Что такое N вообще? Я о таком не слышал.
VK>Шутка конечно, просто я не люблю такие сокращения и меня это немного раздражает.

Во-во я же говорю религиозные чувства
Тут например многих коробит что C++ называют плюсами, я думаю тоже самое чувство виновато
А сокращать полезно, у меня тут автокомплита нет

FR>>Тебе 3 года назад N на ум пришел бы?
VK>Нет не пришел бы, и не прийдет сейчас. А Nemerle три года назад просто не существовало. Но уже были языки, которые во-многом были похожи на Nemerle и мне нравились уже тогда, например OCaml, Scala.

Ocaml из совсем другой оперы, а про Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования

VK>А вообще я не являюсь фанатом ни одного языка. У меня широкий кругозор и постоянно интересуюсь новыми и старыми языками программирования. Мне кстати нравится время от времени писать на языках, которые я знаю очень плохо или совсем не знаю. Это доставляет мне гораздо большее удовольствие чем программирование на уже знакомых и хорошо освоенных инструментах.

Это да
Только если добровольно

VK>А вот Nemerle меня привлекает совсем не новизной и оригинальностью(тем более что я знаком с ним с выхода самой первой версии), а именно как практический инструмент для разработки на .NET. Тем более что он действительно на порядок лучше всего того, что есть для этой платформы.

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

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

_>Если пихать всё, получится perl 6.
У перла 6 я думаю тоже найдутся свои фанаты.

_>Вот мне не нравится ; ставить в конце каждой строки. А зачем? Вот javascript рулит. И что теперь? Почему эти
_>стандартизаторы c#/java и даже немерла такие косные, что не понимают что мне нравится?
Во-первых в Nemerle не всегда обязательно ставить ; в конце строки, а только когда нужно отделить одно выражение от другого. Зачастую функция вообще может состоять из одного выражения. Еще после объявления локальной функции ; не обязательно ставить. В подветках паттерн-мэтчинга и других составных выражений ; ставить не нужно.

Вот кусочек кода в качестве иллюстрации:

variant BinarySearchTree[T] : IEnumerable[T]
    where T : IComparable[T]
{
    | Node
        {
            left : BinarySearchTree[T];
            element : T;
            right : BinarySearchTree[T];
        }
    | Nil
    // ...
    public Add(newElement : T) : BinarySearchTree[T]
    {
        match(this)
        {
            | Node(left, element, right) =>
                match(newElement.CompareTo(element))
                {     
                    | 0  => Node(left, element, right)
                    | c when (c <= -1) => Node(left.Add(newElement), element, right) 
                    | _  => Node(left, element, right.Add(newElement))
                }
            | Nil => Node(Nil(), newElement, Nil())
        }
    }
    // ...
    public static FromList(lst : list[T]) : BinarySearchTree[T]
    {
        lst.FoldLeft(Nil(), (e,a) => a.Add(e))
    }
}

Кроме в Nemerle есть так называемый синтаксис основанный на отступах, как в Питоне. Там ни в каких случаях не нужно ставить ; в конце строки, и даже не нужно пользоваться фигурными скобками. Мне например это не нравится, но судя по Питону и подобным языкам есть любители и такого изврата.

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

_>Если пихать всё, получится perl 6.

Если пихать всё, кроме того что нужно, то получится C++.

_>Вот мне не нравится ; ставить в конце каждой строки. А зачем? Вот javascript рулит. И что теперь? Почему эти стандартизаторы c#/java и даже немерла такие косные, что не понимают что мне нравится?

А ты спроси у комитетчиков, почему такого нет в C++.

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

FR>Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования

Про Scala есть статья на RSDN здесь

Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.

. Интересный язык вобщем-то.

Здравствуйте, Дьяченко Александр, Вы писали:

FR>>Scala я тоже тогда же примерно читал их призентацию, из которой понял что это какая-то явовая муть для проектирования

ДА>Про Scala есть статья на RSDN здесь

Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.

. Интересный язык вобщем-то.

Спасибо я знаю, просто тогда я ничего не понял из их полоумной призентации