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

C>Нет, просто есть копии сборок для 1.0, 1.1 и 2.0.

Где?

VD>Если бы ты знал какую глупость ты сейчас произнес.

+1. Функциональное программирование без сомнения более богатая концепция, чем итераторы. Особенно в том виде, в котором оно присутствует в Nemerle(т.е. хорошо так разбавленном императивным, объектно-ориентированным, обобщенным и генеративным программированием). Пример с FoldLeft это далеко не самый показательный случай.

VD>Я не гуру в этих вопросах но даже мне ясно, что итераторы всего лишь паттерн для перебора последовательности. Между тем есть всего два варианта перебора 1) цикл, 2) рекурсия. FoldLeft — это рекурсивный перебор. На чем он делается уже не важно.

Ну вообще-то есть random access итераторы, output итераторы итд. Они позволяют несколько больше, чем просто перебирать последовательность. Но по сути это неважно. Любой вид итератора можно при большом желании реализовать на C# 2.0 и соотвественно Nemerle. Только вот зачастую это никому не нужно. Слишком узок круг этих задач, где такие итераторы сильно облегчают жизнь. У управляемых языков свой подход к обобщенному программированию и опыт показывает, что для того круга задач которые обычно решаются на управляемых языках такой подход зачастую лучше. И наиболее часто используемые итераторы это все таки итераторы для перебора последовательностей, а они .NET средой поддерживаются(как концепция ) в полной мере.

А что касается FoldLeft(и других подобных функций) и рекурсии, то это необязательно. В Nemerle конечно нет циклов и рекурсия обычно оптимизируется в цикл. А так FoldLeft можно и через обычный цикл реализовать:

def FoldLeft(collection, mutable value, func)
{
    foreach(element in collection)
    {
        value = func(value, element);
    }
    value
}

def numbers = [1, 2, 3, 4];
def product = FoldLeft(_, 1, fun(product, number) { product * number });
Nemerle.IO.printf("%d\n", product(numbers));

Конечно здесь во время компиляции foreach раскроется в while, а while в рекурсию, а рекурсия станет циклом, но это не важно.

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

VD>Можно список координальных доработок за последние 10 лет?

Я говорил о 20-ти годах развития, а не про последние 10 лет
А за последние 10 лет, имхо, самым важным стало:
— уменьшение количества "живых" компиляторов для самых популярных платформ;
— проведенный-таки deadline по предложениям к новому стандарту языка.

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

VD>>Если бы ты знал какую глупость ты сейчас произнес.

VK>+1. Функциональное программирование без сомнения более богатая концепция, чем итераторы. Особенно в том виде, в котором оно присутствует в Nemerle(т.е. хорошо так разбавленном императивным, объектно-ориентированным, обобщенным и генеративным программированием). Пример с FoldLeft это далеко не самый показательный случай.

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

VK>Ну вообще-то есть random access итераторы, output итераторы итд.

access-итераторы — это вообще оксюморон. Все равно что живой мертвец.

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

Именно.

VK> Любой вид итератора можно при большом желании реализовать на C# 2.0 и соотвественно Nemerle. Только вот зачастую это никому не нужно. Слишком узок круг этих задач, где такие итераторы сильно облегчают жизнь.

Скажу болше. Во всем дотнете просто применяются другой набор абстракций. Всесто оксюморонов воде random access iterator в нем есть интерфейсы IList<T> и ICollection<T> выполняющие ту же роль, но имеющие более логичные имена и более простой интерфейс.

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

Опыт показывает, что вообще трудно найти область где код на С++ оказался бы проще и кратче чем на C#. Хотя конечно если постараться, то найти можно. А уж с Немерлом ему точно не тягаться.

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

>> C>Кроме того, я специально спросил ".NET *Framework*".
>> Тогда задайся еще вопросом "Что сложнее .NET *Framework* или Windows".
>> Думаю у тебя выйдет, что .NET Framework сложнее, так как для его
>> реализации придется реализовать Windows как базовый компоенет.
C>Ну вот. В С++ примерно тоже — язык, в котором есть несколько ловушек,
C>требующих для реализации кучу кода.

C>Поэтому ваш аргумент "сложный, а значит плохой" — не совсем правильный.

Вообще не улавливаю связи.

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

>> Можно список координальных доработок за последние 10 лет?
C>Шаблоны с частичной специализацией, метапрограммирование.

Это 1998-ой год. Где же куча изменений?

Да и какой смысл в этих изменениях? Введение убогого функционального языка времени компиляции?

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

E>Я говорил о 20-ти годах развития, а не про последние 10 лет

ОК, давай за 20.

Я знаю только два изменения языка. Можешь назвать третье?

E>А за последние 10 лет, имхо, самым важным стало:
E>- уменьшение количества "живых" компиляторов для самых популярных платформ;
E>- проведенный-таки deadline по предложениям к новому стандарту языка.

Ну, то есть, по-твоему, последние 10 лет было не развитие, а деградация?
Представляешь какова была бы польза для общества, если все эти 20 лет мега-контроы занимались бы развитием действительно мощьного языка и вкладывали бы деньги в их компиляторы и средства разработки?

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

VD> ... Я не гуру в этих вопросах но даже мне ясно, что итераторы всего лишь паттерн для перебора последовательности. Между тем есть всего два варианта перебора 1) цикл, 2) рекурсия. FoldLeft — это рекурсивный перебор. На чем он делается уже не важно.

А вот какой чудесный оказывается бывает итератор

Автор: remark
Дата: 05.03.06

.

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

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

VD>> ... Я не гуру в этих вопросах но даже мне ясно, что итераторы всего лишь паттерн для перебора последовательности. Между тем есть всего два варианта перебора 1) цикл, 2) рекурсия. FoldLeft — это рекурсивный перебор. На чем он делается уже не важно.

I>А вот какой чудесный оказывается бывает итератор

Автор: remark
Дата: 05.03.06

.

О, да, вещь невероятной полезности.

А простота реализации на плюсах!!! Есть чем гардится. Куда там аналогу на C#:

static IEnumerable<T> Repeater<T>(IEnumerable<T> seq)
{
    while (true)
        foreach (T value in seq)
            yield return value;
}

И использование:

static void Main()
{
    foreach (int value in Repeater(new int[] { 1, 2, 3 }))
        Console.Write(value + " ");
}

Сравни на досуге со своим любимым С++. Забавно, что в Нэмерле yield тоже есть, но реализован в виде макроса.

VladD2 wrote:
> А простота реализации на плюсах!!! Есть чем гардится. Куда там аналогу
> на C#:
Кстати, а что там у нас с итераторами для изменяющихся контейнеров? Для
C++ они есть в Boost

А как насчет аналога zip-iterator'а (итератор сразу по нескольким
контейнерам) и его применения для обобщенных алгоритмов?

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

C>VladD2 wrote:
>> А простота реализации на плюсах!!! Есть чем гардится. Куда там аналогу
>> на C#:
C>Кстати, а что там у нас с итераторами для изменяющихся контейнеров? Для
C>C++ они есть в Boost

C>А как насчет аналога zip-iterator'а (итератор сразу по нескольким
C>контейнерам) и его применения для обобщенных алгоритмов?

вот:

    public class Class1
    {
        static IEnumerable<T> Union<T>(IEnumerable<T> one, IEnumerable<T> two)
        {
            foreach (T var in one)
                yield return var;
            foreach (T var in two)
                yield return var;
        }

        static void Main()
        {
            foreach (int val in Union(new int[] { 1, 2, 3 }, new int[] { 5, 6, 7 }))
                Console.Write(val + " ");
            Console.ReadLine();
        }
    }

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

ЗХ>эффект любой строки кода локален и очевиден

С одной стороны, хороший принцип. Вирт со своим Обероном кстати, строго ему следует.

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

ЗХ>Но, с другой стороны: полностью нарушен (я бы сказал, низвергнут с пьедестала и подвержен особо извращенному поруганию) этот самый принцип локальности поведения системы в ответ на строчку моего кода. Я всего лишь объявил переменную какого-то типа, написав "Typename varname;", но эта строчка может привести к вызову неизвестного мне конструктора, а за ним — кода сколь угодно, вообще говоря, сложности. Я всего лишь применяю известный мне оператор к переменной — а он, оказывает, overloaded у этого класса, и черт знает что на самом деле там произойдет. Я всего лишь вышел из функции, что может быть проще, написал }, а в рантайме на самом деле пошли плясать деструкторы всех автоматических объектов в этой функции. И даже и не буду начинать говорить про copy constructor и прочие подобные прелести.

ЗХ>Так вот, поэтому C++ — плохой язык.

Автор пытается использовать С++ как Си. То же самое было, когда ругали дотнет. Баян короче [:|||||:]

anton_t wrote:
> C>А как насчет аналога zip-iterator'а (итератор сразу по нескольким
> C>контейнерам) и его применения для обобщенных алгоритмов?
> вот:
Не подходит. Я могу делать так:

typedef boost::zip_iterator<
     boost::tuples::tuple<
       std::set<int>::iterator,
       std::vector<double>::iterator
       >
     > set_and_vector_iterator;

std::set<int> someSet;
std::vector<double> someVec;

set_and_vector_iterator iter (     
     boost::make_tuple(someSet.begin(),someVec.at(5));
for(;iter!=set_and_vector_iterator();++iter)
{
//Do something
}

Или вот так:

typedef zip_iterator<
     tuple<
       std::deque<int>::iterator,
       std::vector<double>::iterator
       >
     > zip_iter;

std::deque<int> someDeque;
std::vector<double> someVec;

zip_iter begin(make_tuple(someDeque.begin(),someVec.at(5)));
zip_iter end(make_tuple(someDeque.at(11),someVec.at(16)));
std::sort(begin,end);

В этом примере будут отсортированы куски двух массивов. Сравнение
элементов производится сначала по первому элементу тупла, потом по второму.

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

VD> ... Куда там аналогу на C#:

VD>static IEnumerable<T> Repeater<T>(IEnumerable<T> seq)
VD>{
VD>    while (true)
VD>        foreach (T value in seq)
VD>            yield return value;
VD>}

<b>Там</b>

Автор: remark
Дата: 05.03.06

был зацикленный итератор.

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

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

VD>> ... Куда там аналогу на C#:

I>

VD>>static IEnumerable<T> Repeater<T>(IEnumerable<T> seq)
VD>>{
VD>>    while (true)
VD>>        foreach (T value in seq)
VD>>            yield return value;
VD>>}
I>

I><b>Там</b>

Автор: remark
Дата: 05.03.06

был зацикленный итератор.

А тут что, не зацикленный?

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

_>А тут что, не зацикленный?

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

I>

VD>>static IEnumerable<T> Repeater<T>(IEnumerable<T> seq)
VD>>{
VD>>    while (true)
VD>>        foreach (T value in seq)
VD>>            yield return value;
VD>>}
I>

I><b>Там</b>

Автор: remark
Дата: 05.03.06

был зацикленный итератор.

То есть без пары килобайт текста не верится, что что-то заработает?

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

VD>То есть без пары килобайт текста не верится, что что-то заработает?

Ага, так оно и было.

Здравствуйте, Павел Кузнецов, Вы писали:

E>>> Нужно еще Александреску вспомнить, и Абрахамса, и Гуртового и пр. Правда они не столько над языком работают, сколько над стилем его использования. Нужно сказать, что у них получается.
PA>>Это диверсанты-функциональщики на самом деле .

ПК>То-то бы Леша удивился, узнав о себе такое...
.
Ну, во-первых, это была шутка.
Во-вторых, не имею чести быть с ним знакомым, если действительно удивится — дайте знать .
В-третьих, это же очевидно из дизайна MPL — функции высших порядков, ленивое вычисление, partial application (аналог currying), алгоритмы обработки последовательностей реализованы через fold и т.д.;
http://boost.org/libs/mpl/doc/tutorial/higher-order.html — здесь туториал MPL ссылается на статью Paul'а Hudak'а, популяризатора ФП вообще и Haskell в частности.

В конце концов, я лично заинтересовался ФП после знакомства с MPL (коварный план в действии ).

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

VD>ОК, давай за 20.

VD>Я знаю только два изменения языка. Можешь назвать третье?

Вообще-то с памятью у меня не важно, поэтому могу в чем-то ошибиться, но с 1992-го года, когда я начал изучать и использовать C++ изменений в самом языке было довольно много:
-- появилось множественное наследование (имхо, изначально его не было, в 90-х года оно уже было доступно во многих компиляторах, но не везде) и виртуальные базовые классы;
-- отказались от ключевого слова override для перегрузки (имхо, оно еще описывалось в первом издании "Языка программирования C++");
-- добавлено protected-наследование (изначально было только private и public наследование);
-- если не ошибаюсь, был расширен список операторов для перегрузки;
-- добавлена библиотека потокового ввода-вывода (те самые iostream);
-- добавлена поддержка исключений;
-- добавлена поддержка шаблонов (которая, если не ошибаюсь развивалась со временем, например изначально не было возможности объявлять шаблонные методы внутри обычных классов или шаблонные методы внутри шаблонных классов);
-- создана библиотека STL (название которой изначально расшифровывалось как STepanov & Lee, а только затем как Standard Template Library), впоследствии эта библиотека стала стандартной частью C++;
-- добавлены ключевые слова volatile и mutable;
-- добавлены reinterpret_cast, const_cast, static_cast;

И самое главное, что все эти возможности и изменения плавно (к сожалению), с течением времени появлялись во всех более-менее нормальных компиляторах C++. Например, я начал использовать STL где-то в конце 1996-го года и тот STL был просто библиотекой от RogueWare, которую еще к компилятору нужно было прикручивать (в частности, к Watcom C++ 10/11 под OS/2). И помню, сколько было гоморроя по перетаскиванию кода с STL из под одного компилятора в другой. В том же VC++ более-менее нормальная поддержка STL появилась только в 6-й версии.

Так что самое хорошее за последние 10 лет, это то, на большом спектре платформ сейчас можно без проблем использовать нормальное подмножество C++. Хотя и сейчас иногда приходится для некоторых заказчиков связываться с GNU C++ версии 2.95.3.

E>>А за последние 10 лет, имхо, самым важным стало:
E>>- уменьшение количества "живых" компиляторов для самых популярных платформ;
E>>- проведенный-таки deadline по предложениям к новому стандарту языка.

VD>Ну, то есть, по-твоему, последние 10 лет было не развитие, а деградация?

Деградацией вряд ли эти 10 лет можно назвать. Здесь много о чем можно поговорить. Например, о том, что к моменту возникновения C++ в 1983-м году (когда реально действующий компилятор стал доступен для использования) был накоплен большой опыт использования языка C и Страуструпу стало понятно, что он хочет сделать в C++ чтобы облегчить написание программ по сравнению с C. Т.е. к 1983 уже был пройден этап анализа. Последующие 15 лет (до принятия стандарта) можно считать этапом синтеза, на котором C++ принял знакомый нам вид. Следующие годы стали, имхо, очередным этапом анализа. За которым, я надеюсь, будет следующий этап синтеза (в виде следующего стандарта C++ и его реализаций в выживших C++ компиляторах).

Можно еще и с другой стороны глянуть. Это были 10 лет, определивших жизнеспособность C++ в тяжелой конкуретной борьбе (взять хотя бы туже Java в конце 90-х и C# сейчас). C++ выжил. Как оказалось в случае с Java, для Java были созданы новые предметные области, но не было вытеснения C++ из уже занятых ниш.

А можно и еще с одной стороны посмотреть. Сейчас C++ уходит из тех ниш, куда его занесло по воле моды на C++ в 90-х и где вместо C++ хорошо работают managed-языки и среды. И слава богу. Очень замечательно. Чем меньше на C++ будут программировать те, кто не умеет на нем программировать, тем лучше для самого языка. Smalltalk и Lisp тому примеры. Лично я не против того, чтобы С++ стал таким маленьким специализированным корабликом, который решает специфические (не обязательно мейнстримовые) задачи. Лишь бы крыс на нем не было

VD>Представляешь какова была бы польза для общества, если все эти 20 лет мега-контроы занимались бы развитием действительно мощьного языка и вкладывали бы деньги в их компиляторы и средства разработки?

Нет, не представляю. Этого не было.