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

В продолжение http://www.rsdn.ru/Forum/Message.aspx?mid=1659974&only=1

Автор: WolfHound
Дата: 05.02.06

WH>Здравствуйте, c-smile, Вы писали:

CS>>Вопрос №1: пассаж про new Tuple ... в теле цикла я не понял.
WH>Если посмотришь внимательно то это не единственное место к которому можно докопаться.
CS>>Зачем думатель это придумал?
WH>Главное то что думатель вывел все типы, а то что думатель сделал несколько локальных ляпов так это детская болезнь. Просто у ребят физически не хватает ресурсов для того чтобы сделать оптимизацию таких вещей и по этому их компилятор генерирует код по принципу "что вижу то пою".
WH>Уверен что к релизу они эти ляпы исправят.

Не уверен.
В условиях недетерминированного описания (типов в том числе) думатель
будет вынужден "стелить соломку".
Т.е. в принципе чем меньше информации имеет компилятор тем менее оптимальный
код он строит. Более универсальный — да.

VD>>>Получаем краткость скриптов, и мощь компилируемых языков.
CS>>Такая компиляция это не мощь.
WH>А что же? В программе не указано ни одного типа... тем не мение компилятор сгенерировал строго типизированный код. Если это не мошь тогда что же такое мощь?

Вопросы:
1) Что сделает думатель если увидит скажем такое:
hash[key] = flag? 1: "string";
2) C intellisense как я понимаю такой вывод типов дружить не будет?
Т.к. типы становятся известны только после построения syntax tree всей программы.

И философическая часть:

Зачем в принципе нужен такой выводитель типов?
Какие задачи он призван решить или облегчить их решение?
Какие есть средства "детерминизаци": "я хотел сказать А а думатель придумал Б".

Личное замечание:
Такая недетерминированность в C++ является источником очень неприятных и дурных ошибок.
Один раз очень долго искал в чем проблема. Оказалось в наличии двух конструкторов у
объекта: cls(int n) и cls(bool b). (или что-то подобное — не помню)
Я имел ввиду одно а думатель молча выводил другой тип... Причем разные думатели
(компиляторы) думали по разному.

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

CS>Личное замечание:
CS>Такая недетерминированность в C++ является источником очень неприятных и дурных ошибок.
CS>Один раз очень долго искал в чем проблема. Оказалось в наличии двух конструкторов у
CS>объекта: cls(int n) и cls(bool b). (или что-то подобное — не помню)
CS>Я имел ввиду одно а думатель молча выводил другой тип... Причем разные думатели
CS>(компиляторы) думали по разному.

Вот еще один пример "из жизни" (я его, конечно, схематизировал), связанный с этой стороной Си++.
Компилятор спокойно приводит bool к float, как будто так и надо.

#include <stdio.h>

class Float {
    float _float;
public:
    Float(float x) : _float(x) { }

    // следующая строка была закомментирована по ошибке (просто опечатка)
    //operator float() { return _float; }

    // в реальной программе bool() проверяет отличие Float от нуля
    // чтобы обеспечить корректную работу конструкции if (F) ...
    operator bool() { return (_float != 0); }
};

int main()
{
    Float F = 3.1415926536f; // Кто и шутя, и скоро пожелаетъ Пи узнать число, ужъ знаетъ.
    float x = F;
    printf("%f\n", x); // Что напечаталось? Правильно, 1.000000
    return 0;
}

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

CS>>Один раз очень долго искал в чем проблема. Оказалось в наличии двух конструкторов у
CS>>объекта: cls(int n) и cls(bool b). (или что-то подобное — не помню)
CS>>Я имел ввиду одно а думатель молча выводил другой тип... Причем разные думатели
CS>>(компиляторы) думали по разному.

AVC>Вот еще один пример "из жизни" (я его, конечно, схематизировал), связанный с этой стороной Си++.
AVC>Компилятор спокойно приводит bool к float, как будто так и надо.


Люди, зачем вы валите все с больной головы на здоровую? Вот такой пример не скомпилируется, компилятор найдет обе ошибки:

def boolFunc(x : bool)
{
    System.Console.WriteLine("bool: {0}",x);
}

def floatFunc(x : float)
{
    System.Console.WriteLine("float: {0}",x);
}

floatFunc(true);
boolFunc(2.0f);

А вот такой скомпилируется:

module M
{
    f(x : double) : void
    {
        System.Console.WriteLine("fp: {0}", x);
    }

    f(x : long) : void
    {
        System.Console.WriteLine("integer: {0}", x);
    }

    Main() : void
    {
        f(2.0f);
        f(2.0);
        // не помню префиксы
        f(2 : uint);
        f(2 : int);
        f(2 : byte);
        // f('a'); // ошибка компиляции, не найдено подходящей перегрузки
        // f(true); // аналогично
    }
}

В Nemerle семантика в данном случае похожа на C#(а может и вообще совпадает). Есть неявное приведение типов, но только для числовых типов(int, float, double, и т.п.) и таких проблемы как в C++ с неявным приведением нет и быть не может. Ни char, ни bool, ни что-либо подобное числовыми типами не считается и подобная ошибка абсолютно исключена(привести к числовым эти типы можно только насильно). Так что это проблема только C/C++.

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

CS>В условиях недетерминированного описания (типов в том числе) думатель
CS>будет вынужден "стелить соломку".

Такий условий нет "бай-дизайн". Любое разночтение интерпретируется как ошибка. "Думатель" делает выводы только если ситуация полностью детерминирована.

CS>Т.е. в принципе чем меньше информации имеет компилятор тем менее оптимальный
CS>код он строит. Более универсальный — да.

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

CS>Вопросы:
CS>1) Что сделает думатель если увидит скажем такое:
CS> hash[key] = flag? 1: "string";

Для Нэмерла этот код будет "звучать" так:

hash[key] = if (flag) 1 else "string";

и на него компилятор банально гавкнет:

expected int-, got string in computation branch: common super type of types [int, string] is a set of interfaces

то есть, просто не даст так сделать.

CS>2) C intellisense как я понимаю такой вывод типов дружить не будет?

А какая разница то кому делать вывод типов? Будет такой же вывод делать парсер интелисенса.

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

def hash = Hashtable<string, int>();

а не
Hashtable<string, int> hash = Hashtable<string, int>();
как это сейчас происходит в С++ и C#.

CS> Т.к. типы становятся известны только после построения syntax tree всей программы.

Они приципиально до этого не доступны. Любой интелисенст парсет все файлы проекта и крайне плохо относится к наличию ошибок в них.

Собственно пока типы ключей и значений имеют которкие имена, то замусоривания не так видно. Но когда это длинные типы темблее сами содержащие длиннющие параметры типов, то выходит довольно ужасно выглядящий код. Например, объявление той же хэш-таблицы может переноситься на две строки, чтобы влезнь в правила форматирования заставляющие переносить строки по 80 символов. C#:

Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName>>, List<MySecondClassWithLongName>> dic =
    new Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName>>, List<MySecondClassWithLongName>>();
dic.Add(var1, var2);

C++:

Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ dic^ =
    new Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ ();
dic->Add(var1, var2);

Nemerle:

def dic = Dictionady();
dic.Add(var1, var2);

CS>И философическая часть:

CS>Зачем в принципе нужен такой выводитель типов?

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

CS>Какие задачи он призван решить или облегчить их решение?

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

Это как бы развитие идеии которую пытаются протлкнуть в следующую версию С++ (ключевое слово auto).

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

def hash = Hashtable ();

def Init(x, y)
{
    foreach (value in y)
        x.Add(value[0], value[1]);
}

Init(hash, [("1", 1), ("2", 2)])

А так спокойно описал. И выглядит кратко.

CS>Какие есть средства "детерминизаци": "я хотел сказать А а думатель придумал Б".

Компилятор ничего не выдувывает. Это ты думатель. А он дететриминованный конечный автомат.
Ты можешь помочь ему задв тип при объявлении переменой, а можешь положиться на его "разумность".

CS>Личное замечание:
CS>Такая недетерминированность в C++ является источником очень неприятных и дурных ошибок.

В Нэмерле нет недетерминированностей. Точнее если и есть, то по шибке. Авторы их не планировали.
А С++ спроектирован так... Короче о нем просто не хочу говорить.

CS>Один раз очень долго искал в чем проблема. Оказалось в наличии двух конструкторов у
CS>объекта: cls(int n) и cls(bool b). (или что-то подобное — не помню)
CS>Я имел ввиду одно а думатель молча выводил другой тип... Причем разные думатели
CS>(компиляторы) думали по разному.

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

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

Думаю твой пример на этом:
AVC>Вот еще один пример "из жизни" (я его, конечно, схематизировал), связанный с этой стороной Си++.
можно было бы и закончить.

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

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

VK>А вот такой скомпилируется:
VK>

VK>        f(2.0f);
VK>        f(2.0);
VK>        // не помню постфиксы
VK>        f(2 : uint);
VK>        f(2 : int);
VK>        f(2 : byte);
VK>}
VK>

Результат:

fp: 2.0
fp. 2.0
integer: 2
integer: 2
integer: 2

Не сверхестественный результат, как раз такой и должен быть.

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

VD>C++:
VD>

VD>Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ dic^ =
VD>    new Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ ();
dic->>Add(var1, var2);
VD>

Typedef уже отменили?
А то бы получилось:

typedef Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ MyDictionaryPtr;
...
MyDictionaryPtr dic^ = new MyDictionaryPtr;

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

VD>def hash = Hashtable ();

VD>def Init(x, y)
VD>{
VD>    foreach (value in y)
VD>        x.Add(value[0], value[1]);
VD>}

VD>Init(hash, [("1", 1), ("2", 2)])
VD>

VD>А так спокойно описал. И выглядит кратко.

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

VD>Не пишите на дурно спроектированных языках и не будете искать шибки очень долго.

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

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

Disclaimer: Nemerle знаю только на основе предыдущих постов, сказанное ниже оносится скорее к O`Caml. Думаю, это не будет оффтопиком, так как проблема обсуждается с глобальной точки зрения

CS>Не уверен.
CS>В условиях недетерминированного описания (типов в том числе) думатель
CS>будет вынужден "стелить соломку".
CS>Т.е. в принципе чем меньше информации имеет компилятор тем менее оптимальный
CS>код он строит. Более универсальный — да.

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

Вообще, почитай про реконструкцию типов (например, алгоритм унификации типов Хиндли-Милнера). TAPL.

CS>Вопросы:
CS>1) Что сделает думатель если увидит скажем такое:
CS> hash[key] = flag? 1: "string";

В O`Caml алгоритм унификации (выведения типов) выдаст ошибку.

CS>2) C intellisense как я понимаю такой вывод типов дружить не будет?
CS> Т.к. типы становятся известны только после построения syntax tree всей программы.

Во-первых, необязательно всей. Незнаю как в Nemerle, но в O'Caml можно давать явные аннотации типов. Во-вторых, IntelliSense может подсказывать те конструкции при введении которых алгоритм унификации выдает не пустое множество решений (т.е унификация типов возможна).

CS>И философическая часть:

CS>Зачем в принципе нужен такой выводитель типов?
CS>Какие задачи он призван решить или облегчить их решение?

Проще писать программу (можно не задумываться о типах там, где это не нужно), компактнее код.

CS>Какие есть средства "детерминизаци": "я хотел сказать А а думатель придумал Б".

Аннотации типов, естественно. Где типы важны для тебя — ставишь аннотации. Где не важны — не ставишь и, соответственно, не ошибаешься в указании типа

CS>Личное замечание:
CS>Такая недетерминированность в C++ является источником очень неприятных и дурных ошибок.
CS>Один раз очень долго искал в чем проблема. Оказалось в наличии двух конструкторов у
CS>объекта: cls(int n) и cls(bool b). (или что-то подобное — не помню)
CS>Я имел ввиду одно а думатель молча выводил другой тип... Причем разные думатели
CS>(компиляторы) думали по разному.

Во-первых, это немного другое. В твоем случае это больной subtyping и ad-hoc полиморфизм (aka overloading), насколько я понимаю. Но тоже имеет отношение к системе типов, а потому отслыаю опять к TAPL. Кстати, вот [http://lambda-the-ultimate.org/node/1113#comment-12147]тут[/url] (первое, что нашел в Google) есть мысль по этому поводу.

А во-вторых, вывод типов полностью детерминирован (это было бы странно, если бы он работал пользуясь "догадками" и "эвристиками", хотя не буду утверждать, что такого не бывает ). Открыв книгу, указанную выше, ты можешь найти описание алгоритма для ML-like языка.

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


VD>Для Нэмерла этот код будет "звучать" так:
VD>

VD>hash[key] = if (flag) 1 else "string";
VD>

VD>и на него компилятор банально гавкнет:
VD>

VD>expected int-, got string in computation branch: common super type of types [int, string] is a set of interfaces
VD>

VD>то есть, просто не даст так сделать.

Спасибо. Это я понял.

CS>>2) C intellisense как я понимаю такой вывод типов дружить не будет?

VD>А какая разница то кому делать вывод типов? Будет такой же вывод делать парсер интелисенса.
VD>В первй строке он конечно ничего умного не предложит. Но в следующих уже предложет.
VD>К тому же всегда можно задать тип при его создании. Только в отличии от большинства других языков однин раз.
VD>

VD>def hash = Hashtable<string, int>();
VD>

VD>а не
VD>Hashtable<string, int> hash = Hashtable<string, int>();
VD>как это сейчас происходит в С++ и C#.

Я не вижу принципиальной разницы в написании

Hashtable<string, int>() hash;

и

def hash = Hashtable<string, int>();

CS>> Т.к. типы становятся известны только после построения syntax tree всей программы.

VD>Они приципиально до этого не доступны. Любой интелисенст парсет все файлы проекта и крайне плохо относится к наличию ошибок в них.

Это очень дорогая операция парсить все файлы. Это не для GUI.

VD>Собственно пока типы ключей и значений имеют которкие имена, то замусоривания не так видно. Но когда это длинные типы темблее сами содержащие длиннющие параметры типов, то выходит довольно ужасно выглядящий код. Например, объявление той же хэш-таблицы может переноситься на две строки, чтобы влезнь в правила форматирования заставляющие переносить строки по 80 символов. C#:
VD>

VD>Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName>>, List<MySecondClassWithLongName>> dic =
VD>    new Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName>>, List<MySecondClassWithLongName>>();
VD>dic.Add(var1, var2);
VD>

VD>C++:
VD>

VD>Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ dic^ =
VD>    new Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ ();
dic->>Add(var1, var2);
VD>

VD>Nemerle:
VD>

VD>def dic = Dictionady();
VD>dic.Add(var1, var2);
VD>

Несколько надуманный пример, имхо. Честно говоря такого безобразия я в своей практике не встречал.
Может из-за того что я ни stl ни boost не использую в быту?

CS>>И философическая часть:

CS>>Зачем в принципе нужен такой выводитель типов?

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

Еще раз с интеллисенсом не все так хорошо как ты написал. Запуск полномасштабного парсера (даже без кодогенерации)
на каждый введенный nmtoken это нереально.

На таких принципах можно и для скриптов intellisense строить. Что
кстати и сделано в VS. Там это правда работает для сугубо простых случаев.

CS>>Какие задачи он призван решить или облегчить их решение?

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

VD>Это как бы развитие идеии которую пытаются протлкнуть в следующую версию С++ (ключевое слово auto).

В принципе мотивация понятна.
Я просто думал что это решает некие принципиальные вещи.

Лично для меня явно определить тип всегда лучше — лишний checkpoint
который отлавливается в compiletime и сразу, а не в runtime.

Кстати Вальтер добавил в D auto т.е. такое вот работает:
auto i = 2+2;

Пока случая не представилось воспользоваться.

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

VD>>Не пишите на дурно спроектированных языках и не будете искать шибки очень долго.

E>Ага, а пока появятся хорошо спроектированные языки не программируйте ничего.
E>И совсем уж философский вопрос: неужели за все время развития программирования еще не было создано ни одного нормально спроектированного языка?
E>И что заставляет думать, что через некоторое время кажущийся нормально спроектированным язык не окажется объявленным дурно спроектированным?

Наблюдая плавное переливание Влада из C# в N# я тоже задаюсь этим вопросом.

И вообще нет идеальных языков для всего и вся.

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

WF>Здравствуйте, c-smile, Вы писали:

WF>Disclaimer: Nemerle знаю только на основе предыдущих постов, сказанное ниже оносится скорее к O`Caml. Думаю, это не будет оффтопиком, так как проблема обсуждается с глобальной точки зрения

CS>>Не уверен.
CS>>В условиях недетерминированного описания (типов в том числе) думатель
CS>>будет вынужден "стелить соломку".
CS>>Т.е. в принципе чем меньше информации имеет компилятор тем менее оптимальный
CS>>код он строит. Более универсальный — да.

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

Еще раз мне представляется проблема несколько надуманной.
На Java я пишу немного в последнее время. А в C++ автоматический вывод типов
я из своей практики исключил. И лучше бы его там не было вообще.

WF>Вообще, почитай про реконструкцию типов (например, алгоритм унификации типов Хиндли-Милнера). TAPL.

Ага, спасибо. Но в другой жизни уже. В этой я чукча — писатель.

CS>>Вопросы:
CS>>1) Что сделает думатель если увидит скажем такое:
CS>> hash[key] = flag? 1: "string";

WF>В O`Caml алгоритм унификации (выведения типов) выдаст ошибку.

Почему? А если я так хочу и согласен на boxing например или на какой-нибудь variant?

CS>>2) C intellisense как я понимаю такой вывод типов дружить не будет?
CS>> Т.к. типы становятся известны только после построения syntax tree всей программы.

WF>Во-первых, необязательно всей. Незнаю как в Nemerle, но в O'Caml можно давать явные аннотации типов. Во-вторых, IntelliSense может подсказывать те конструкции при введении которых алгоритм унификации выдает не пустое множество решений (т.е унификация типов возможна).

Проблема intellisense тут давеча обсуждалась а приложении к SELECT ... FROM.
Это оно как мне кажется, нет?

CS>>И философическая часть:

CS>>Зачем в принципе нужен такой выводитель типов?
CS>>Какие задачи он призван решить или облегчить их решение?

WF>Проще писать программу (можно не задумываться о типах там, где это не нужно), компактнее код.

CS>>Какие есть средства "детерминизаци": "я хотел сказать А а думатель придумал Б".

WF>Аннотации типов, естественно. Где типы важны для тебя — ставишь аннотации. Где не важны — не ставишь и, соответственно, не ошибаешься в указании типа

"не ошибаешься в указании типа". Если я ошибусь мне компайлер скажет.
А в твоем случае скажет unittest. Который еще писать надо.

Но это так. Еще раз — мотивацию понимаю. Просто думал что это что-то принципиально новое позволяет делать...

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

CS>Еще раз мне представляется проблема несколько надуманной.
CS>На Java я пишу немного в последнее время. А в C++ автоматический вывод типов
CS>я из своей практики исключил. И лучше бы его там не было вообще.

Интересно, как можно говорить о некоторой возможности если ты даже с ней не работал (впечатление такое сложилось)?

WF>>Вообще, почитай про реконструкцию типов (например, алгоритм унификации типов Хиндли-Милнера). TAPL.

CS>Ага, спасибо. Но в другой жизни уже. В этой я чукча — писатель.

..и даже не хочешь узнать, что это за фича и как она работает.

WF>>В O`Caml алгоритм унификации (выведения типов) выдаст ошибку.

CS>Почему? А если я так хочу и согласен на boxing например или на какой-нибудь variant?

В O`Caml disjoint union-ов нет. Но ничто не мешает использовать в данном случае joint union.

Если под "боксингом" ты имеешь ввиду полиморфизм (т.е когда в массиве хранится некий Object или т.н "Top"), то ситуация такая. (далее идут мои, возможно ошибочные, размышления). Вообще говоря, можно ввести тип Top, однако в силу статичности O`Caml его смысл несколько теряется (т.к ты все равно с этим типом потом ничего осмысленного не сделаешь).

CS>Проблема intellisense тут давеча обсуждалась а приложении к SELECT ... FROM.
CS>Это оно как мне кажется, нет?

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

WF>>Аннотации типов, естественно. Где типы важны для тебя — ставишь аннотации. Где не важны — не ставишь и, соответственно, не ошибаешься в указании типа

CS>"не ошибаешься в указании типа". Если я ошибусь мне компайлер скажет.
CS>А в твоем случае скажет unittest. Который еще писать надо.

Нет. Тип выведется. И в худщем варианте, выведется более общий тип, чем ты указал бы.

CS>Но это так. Еще раз — мотивацию понимаю. Просто думал что это что-то принципиально новое позволяет делать...

Да, позволяет. Работать с очень сложными типами. Пример — монады (а еще лучше Arrows Хаскелля ). Посмотрел бы я на того маньяка, кто захочет везде явно типы указывать Ты указываешь типы для граничных случаев (там где ввод/вывод, например), а все остальные внутренние сложные типы выводятся автоматически.

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


CS>Это очень дорогая операция парсить все файлы. Это не для GUI.
Ты видел resharper? Он не только парсит файлы, он производит куда более сложный анализ. Парсить файлы — единственный способ для нормального рефакторинга/intellisense. В Nemerle поддержка редакторов предпологается вообще с помощью встраивания компилятора(естественно не все его стадии, только парсинг и построение AST). Собственно какую-то раннюю версию этой библиотеки я видел в исходниках компилятора. Проблема со скоростью — не проблема на hi-end машинах(например vs2005 на других и работать толком не будет). Потом Nemerle и аналогичные языки рассчитаны на достаточно далекую перспективу, а закон Мура еще никто не отменял.

CS>Еще раз с интеллисенсом не все так хорошо как ты написал. Запуск полномасштабного парсера (даже без кодогенерации)
CS>на каждый введенный nmtoken это нереально.

Это вполне реально и работает.

CS>Лично для меня явно определить тип всегда лучше — лишний checkpoint
CS>который отлавливается в compiletime и сразу, а не в runtime.

Никто не говорит, что этого делать нельзя. Более того даже в Nemerle это иногда делать необходимо. Но если этого не делать в тех случаях, когда это можно, то ошибки всплывут именно в compiletime, а не в runtime. И я не видел еще ни одного случая, когда бы это было не так.

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

E>Typedef уже отменили?
E>А то бы получилось:
E>

E>typedef Dictionady<MyFirstClassWithLongName<List<MySecondClassWithLongName^>>^, List<MySecondClassWithLongName^>>^ MyDictionaryPtr;
E>...
E>MyDictionaryPtr dic^ = new MyDictionaryPtr;
E>

Нет. Как и using. Но это тот же лишний код. Зачем он если без него очень даже неплохо получается?

E>После программирования с RubyOnRails я думаю, что это не есть хорошо.

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

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

Хм. Нэмерл выводит типы. Это всеравно что вписывать их явно. Так что ошибок быть не может. Язык статически типизированный!

Когда я тебе говорил о том, что проблема Руби отсутствие статической типизации ты мне все время возражал и говрил, что все ОК, плюс есть юнит-тесты и т.п. Сейчас же сам себе возражаешь.

Сдается мне, что ты пытайся отстоять свое даже вопреки здравой логике.

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

VD>>Не пишите на дурно спроектированных языках и не будете искать шибки очень долго.

E>Ага, а пока появятся хорошо спроектированные языки не программируйте ничего.

Яве уже сто лет. C# 4. Так что самое время возиться с С++ и Руби. Их тандем позволяет сделть систему и запутаннее, и медленнее, и бажливее. Шучу конечно, но в каждой шутке...

E>И совсем уж философский вопрос: неужели за все время развития программирования еще не было создано ни одного нормально спроектированного языка?

Почти все новые языки лучше своих прототипов. С++ несравненно лучше С. C# ле... в общемя, ф промолчу.
Лучше скажу, что сейчас новые языки пытаются стать лучше чем свои предшественники и рано или поздно у кого-то это получится.

Бывает, конечно, что новый язык впитывает кучу проблем и становится хуже прототипов. Но бывает же и наоборот.

Нэмерл впитал в себя:
1. Антиграблевость и простоту применения C#.
2. Заимствовал лучшие вещи из синтаксиса С, Паскаля, C#, Питона и других.
3. Идеи функционального подхода из ML-клонов.
4. Макросы из клонов Лиспа.

Он поддерживает все известные мне парадигмы программирования. Причем делает это не случайно как С++ и не ограничено как многие языки, а намеренно и от того вроде как полно и не противоречиво.

На нем можно писать в функциональном стиле не хуже чем на МЛ. Он поддерживает и линивость, и одновременно yeld в чтиле Руби/Питона/Шарпа. Он намеренно поддерживает метапрограммирование. Причем делает это великолепно. Фнуциональные возможности упрощают создание макросов, а от того делают их применение доступнее для людей. Код в императивном стиле на нем мало отличим от такого же кода на C# только выглядит более кратно и если что нет проблем воспользоваться любой другой парадигмой.

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

E>И что заставляет думать, что через некоторое время кажущийся нормально спроектированным язык не окажется объявленным дурно спроектированным?

А ничего и не заставляет. Когда я познакомился с С, я вообще ничего другого не видел, но по словам отца — это был самый современный и развитой язык на тот момент. Когда я задолбался тужится писать ОО-код на С и познакомился с С++ я был в щенячьем восторге от того как логично и красиво в нем реализован ООП! Шаблоны в те времена были еще далекти от того чем они стали сейчас. Мне они были не нужны. Но я все равно радовался как ребенок (возможно, потому что тогда я действительно был тогда почти ребенком и гомонов было через край) от раскрывшихся возможностей и невиданной мной до этого простотой.

Потом я радовался новым версиям С++ с шаблонами и вновь появившейся простоте. Тогда я еще не в силах был понять всю ущербность дизайна С++, а о многих концепциях вообще не знал.

Потом я радовался, изучая КОМ, так как получил в свои руки небывалую мощь компонетных технологий!

Далее я радовался, изучая Васик и Дельфи. Их компонентные модели были очень и очень впечатляющие. А визуальные дизайнеры форм в купе с компонентным подходом ускоряли создание ГУИ на порядки. Я вспоминал как недели убивал на приличный оконный интерфейс на С и с удовольствием наблюдал как намного более мощный интерфейс лепится из компонентов прямо на глазах.

Потом я примерно с твоим скепсисом наблюдал за появлением Явы. Я произвел пару тестов и выяснил, что скорость получаемого кода в десятки раз меньше чем у аналогичного на С++. Я не заметил в Яве мощной компонентной модели и заметил, что то на что ее нацеливают (создание апплетов для Web-а) не входит в круг моих интересов. Так я проморгал первую интересную вещь.

Я делал КОМ-компоненты на С++ и использовал их из Васика получая тем самым преимущества от гибкости С++ и скорости разработки Васика. Подспудно я понимал, что Дельфи в некотором роде является комплексной альтернативой, но количество багов в Дельфи, откровенно слабые библиотеки не связанные с ГУИ, и отсутствие некоторых вкусностей С++ заставили меня выбрать связку С++/Васик.

Далее я наблюдал за дотнетом. В дотнете я обнаружил C# который позволил мне делать все то что я раньше мог делать только на связке С++/Васик/КОМ на одном языке получая при этом куда более простые и безопасные решения. Дотнет и Шарп дали мне еще один повод для радости. Код на Шарпе был реально проще, а значит я смог делать куда больше за то же время.

Ранее я очень страдал, что даже самая крутая хреновина улучшающая комплит в VC++ 6,0 (забыл как ее помню только что фирма была про помидоры "Тамата") постоянно ошибалась на шаблонах С++ и не давала писать дефствительно быстро. Этих проблем не было на Васике, где комплит работает почти изумительно, но гибкость и производительность Васика была ниже плинтуса. В Шарпе же комплит стал еще круче чем в Васик, а язык очень даже сопоставим по гибкости с любимыми до этого плюсами. Вроде бы по отдельности все что было в Шарпе и дотнете я мог получить и ранее, но вместе этого не было нигде.

Так же стоит отметить и библиотеки. 80, если не больше, процентов времени работы на С++ мы уделяли разработке собственных библиотек. С Интернетом тогда было хреново, Буста еще не было, про разные Асе или КуТи мы просто не слышали. Все приходилось делать с нуля. Опыт применения чужого кода оказался горьким, так как в нем были баги, чужие баги связанные с нарушением типобезопасности искать в С++ ой как не просто. В общем, мы быстро приняли для сбея правило — все что используется должно быть написано нами и лежать в исходном коде! Так вот на Шарпе я впервые ощутил, что есть огромная полезная библиотека код которой не страшно использовать. Так же оказалось, что чужой код написанный на Шарпе не так страшно применять в своем коде. Ведь в нем невозможны ошибки связанные с типами и почти все грабли С++, а логические ошибки довольно легко обнаруживаются и устраняются или обходятся во время эксплуатации.

Еще одним достоинством, которое я не смог оценить сразу, но оценил потом было то, что дотнетные библиотеки легко декомпилировались. Сначало Анакрино, а потом и Рефлектор открыли для меня одну важную мысль. Отлаживаться имея возможность быстро найти код используемых библиотек — это очень большое преимущество. Используя С++ я не мог заглянуть в кишки КОМ-а и мы море времени проводили из-за того, что не верно поняли документацию, или в следствии того, что в недоступном коде был баг, а возможно просто что-то прощелкали, мы тратили тоже не мало времени. Теперь же, когда у меня в руках Рефлектор, я быстро могу найти нужный мне библиотечный метод и поглядеть его логику. Сделав это я могу понять в чем я был не прав или найти ошибку в чужом коде. Только недавно нашел ошибку в обертке над ListView. Я очень долго бы просидел над ее поиском если бы я не смог поглядеть ее код. Тут же, я быстро ее обнаружил, и смог понять, как ее легко обойти. На С++ даже имея исходники я не мог так быстро найти нужные мне места, а так как в большинстве случаев и исходников небыло, то был вообще каюк. Я конечно знаю, что сейчас есть разные Доксигены, но тогда их не было! Да и без исходников обходится.

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

С SQL я тоже познакомился забавнейшим образом. Обучаясь программировать на С/С++ я быстро понял, что для решения стоящих передо мной задач мне нужно нечто обеспечивающее простую манипуляцию данными. Причем так чтобы этих могло быть много. В общем, мне была нужна СУБД. То что это называется БД, мен сказали добрые люди. Один знакомый отца дал мне библиотеку позволяющую манипулировать БД типа DBASE на С/С++ (вроде называлась CODBASE). Я довольно быстро научился вытягивать данные табличек, но как вынуть только их нужную часть, да еще и отсортированную нужным образом сразу не просек. После долгого копания я понял, что нужно использовать странные сущности вроде индексов и т.п. Короче нужно делать кучу работы о которой я не подозревал и которая по большому счету мне и на фиг не уперлась.

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

Через некоторое время я познакомился с ребятами из маленькой конторы которые рассказали мне про то что есть такие штуки как SQL и SQL-серверы. А так же относительно дешевый SQL-сервер Gupta SqlBase и невероятное, по тем временам, визульаное средство SqlWindows. Это было время кода Васика или вообще небыл, или был Васик 1.0 настолько убогий, что с SqlWindows он никак не мог сравниться. Чуть спустя появилась NT и Эксес. Я быстро осознал, что будущее за серверами приложений, SQL-лем и средствами быстрой разработки вроде SqlWindows. Кстати, Дельфи появилась точно позже.

В общем, я чуть отвлекся... Познакомившись с ФЯ я обнаружил, что в них, таких не понятных и таких непривычных есть нечто привлекательное. Они действительно обладают чертами декларативности и код на них может быть значительно более кратким чем привычный мне императивный. Но та неинтуитивнасть которая присутствовала в функциональных примерах, дурацкая манера разворачивать смысл программы по сравнению с естественными языками и совершенно дурацкая манера называть переменные и функции так чтобы никто не догадался (с) операция "Ы", сильно смущали меня.

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

Но главное я осознал — это то, что и ФЯ есть рациональное зерно. А еще "более главное" , то что за декларативностью будущее! Пусть полный отказ от императивных конструкций — это утопия. И пусть пока еще нет ФЯ который я счел бы удобным для сбея, но в этом что-то есть!

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

Если подумать, то чем так хвастаются апологеты ФЯ:
1. Функции как первоклассные сущности.
2. Списки как первоклассные сущности (иными словами упрощенная работа со списками).
3. Использование рекурсии в программах.
4. Сопоставление с образцом.
5. Метапрограммирование.
Ничего не забыл?

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

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

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

И пусть, не многие еще могут понять мощь которую несут эти языки. Пусть на их пути стоят такие непреодолимые препоны как:
1. Фанатизм приверженцев тех или иных имеющихся технологий.
2. Закостенелость мышления большинства.
3. Приверженность людей к своим привычкам. (О сколько раз я наблюдал, как люди понимают, что печатать методом слепой десятипальцовой печати намного эффективнее, но по тыркавшись бросающих попытки научиться ему).
4. Мощь гигантов индустрии вроде MS, Sun или IBM не до конца осознавших куда нужно двигаться. Причем, похоже, что они осознают куда нужно двигаться, но боятся, что факторы идущие в этом списке выше приведут их усилия в тупик.

Но движение в нужном направлении видно. Гиганты индустрии во всю развивают декларативные подходы. Они встраивают в свои модерновые языки декларативные конструкции (C# 1/2, Ява 1.5). Они поддерживают исследования в области ЯП. Они занимаются визуальными дизайнерами и ищут пути внедрения DSL-подхода в реальную жизнь. В общем, они двигаются вперед. Хотя, возможно, и не так быстро как хотелось бы.

Что же касается до того что в будущем могут появиться подходы, которые мы пока не видим, или в которых мы пока не уловили конструктивного зерна, так я этого не боюсь. Собственно для этого я и рассказывал все вышесказанное. Это будет всего лишь следующий шаг. Я только "за" новые шаги. И чем более радикально этот шаг упростит нашу жизнь, тем лучше.

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

ЗЫ

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

На сегодня я вижу перспективу за компонентными управляемыми средами вроде дотнета и Явы. За типобезопасностью, статической типизацией, декларативностью, метапрограммированием, и многим другим. И из всего что я вижу Нэмерле и Скала являются самыми перспективными вещами. Но я уже очень давно подсел на иглу под названием хорошая IDE (под которыми на сегодня я понимаю только два продукта VS, причем только 2005 или 2003 + ReSharper) и IDEA. Остальное не стоит даже обсуждения. Чуть-чуть сюда приблизился Эклипс. Но по многим характеристикам он уступает. В общем, без хорошей IDE моя производительность на C# значительно выше чем на супер пупер Нэмерле. Но я почти уверен, что со временем или C# впитает в себя все преимущества Нэмерла, или Нэмерле обзаведется поддержкой мощной IDE (для начала хватило бы хорошего комплита). Ну, или появится нечто лучше чем Шарп и Нэмерл вместе взятое обладающее офигительной IDE, а возможно и тем самым "чем-то новым о чем мы еще не знаем" и вот именно это и станет моим фаворитом на некоторое время.

А потом (если буду жив) я снова буду сидеть в форуме и бороться с закостенелыми фанатами устаревших технологий вроде C# 5.0 и Нэмерле 3.0 и они мне будут говорить, что я фанатик и вообще несдержанный идиот. Главное не влиться в стройные ряды рядов совсем экзотических извращений или в ряды старперов по духу защищающих пережитки прошлого.

Вот такая я бяка.

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

VD>Хм. Нэмерл выводит типы. Это всеравно что вписывать их явно. Так что ошибок быть не может. Язык статически типизированный!

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

VD>Сдается мне, что ты пытайся отстоять свое даже вопреки здравой логике.



Имхо, между объявлением в Ruby:

def make_report(report_params) ... end

и объявлением в Nemerle:

def make_report( report_params: ReportParams  ) : Hash

нет принципиальной разницы. Без разглядывания подробностей реализации make_report нельзя сказать, что находится в Hash.
Только Nemerle будет давать по рукам во время компиляции (если будет явное нарущение, а то ведь он может и сам какие-то типы вывести). Это хорошо.

Но лучше, когда объявление метода будет вида:

def make_report( report_params: ReportParams ) : Hash< string, ReportData >

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

hash< string, ReportData > make_report( const ReportParams & report_params )

не видно

VD>1. Антиграблевость и простоту применения C#.

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

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

E>Имхо, между объявлением в Ruby:
E>

E>def make_report(report_params) ... end
E>

E>и объявлением в Nemerle:
E>

E>def make_report( report_params: ReportParams  ) : Hash
E>

E>нет принципиальной разницы.

Есть! И приципиальная! В Нэмерле тип выражения известен во время компиляции со всеми вытекающими из этого проверками.

И вот еще что. Заметь! Ты сравнивашь скриптовый язык с языком который по всем параметрам кроме простоты или не уступает, или привосходит С++. А в простоте он его делает как катентка.

Не плохо, правда? Статически типизированный стрипт! Кстати, у Нэмерла есть нечто вроде интерпретатора.

E> Без разглядывания подробностей реализации make_report нельзя сказать, что находится в Hash.

Это в Руби нельзя. А в Нэмерле можно. Даже наоборот нельзя по другому.

E>Только Nemerle будет давать по рукам во время компиляции (если будет явное нарущение, а то ведь он может и сам какие-то типы вывести). Это хорошо.

Именно.

E>Но лучше, когда объявление метода будет вида:
E>

E>def make_report( report_params: ReportParams ) : Hash< string, ReportData >
E>

E>тогда прототим метода будет полностью его документировать. Но тогда особой разницы между этим вариантом и
E>

E>hash< string, ReportData > make_report( const ReportParams & report_params )
E>

E>не видно

Тебе уже раз 5 сказали, что в немерле вольности с типами допускаются только в рамках одного метода. Все глобальные сущьности, в том числе, методы, их параметры, свойства и поля обязаны обявляться явно. Сделано это именно в целях документирования, минимизации ошибок и ускорения компиляции. То есть весь код можно писать не обращая внимание на типы. А вот члены класса прийдется опиысывать полностью. И это правильно!

VD>>1. Антиграблевость и простоту применения C#.

E>Об этом сейчас я бы не стал судить. Макросы в Nemerle это отдельная и большая поляна для грабель.

Макросы писать не обязательно. И отлаженный макрос способен вызвать только те грабли которе ты сам лично туда зложил. Эдак и на C# можно граблей понавтыкать если, например, сделать неявных приведений к булеву типу у чего попало. Но люди же разумны.

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

VD>>

VD>>def hash = Hashtable<string, int>();
VD>>

VD>>а не
VD>>Hashtable<string, int> hash = Hashtable<string, int>();
VD>>как это сейчас происходит в С++ и C#.

CS>Я не вижу принципиальной разницы в написании

Принципиальная разница в том, чо мжно и без <string, int>, как ты мог заметить.
А так же в универсальности. def задает неизменяемую переменную которая может быть локальной функцией, ссылкой на тип...

VD>>Они приципиально до этого не доступны. Любой интелисенст парсет все файлы проекта и крайне плохо относится к наличию ошибок в них.

CS>Это очень дорогая операция парсить все файлы. Это не для GUI.

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

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

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

CS>Может из-за того что я ни stl ни boost не использую в быту?

Может.

CS>Еще раз с интеллисенсом не все так хорошо как ты написал.

Вывод типов не проблема для интелисенса. Вот макросы — длугое дело. Но вроде как работы над этим делом уже ведутся. Интелисенс делают прямо на базе компилятора.

CS> Запуск полномасштабного парсера (даже без кодогенерации)
CS>на каждый введенный nmtoken это нереально.

Если его научить парсить отдельную функцию, то без проблем. И вообще, чем по-твоему отличается "полномасштабный парсер" от парсера для интелисенса? Это толко у С++ с этим проблемы в следствии кучи неоднозначностей и инклюдов.

CS>На таких принципах можно и для скриптов intellisense строить.

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

CS> Что
CS>кстати и сделано в VS. Там это правда работает для сугубо простых случаев.

Если ты про ASP (то что было до дотнета) и про старую студию, то там как раз и использовался вывод типа. Правда так как скрипты позвляли это делать плохо, то и результат был очень ограниченным. Тут же гарантируется 100%-ный вывод типов.

CS>В принципе мотивация понятна.
CS>Я просто думал что это решает некие принципиальные вещи.

А разве краткость кода как в Питоне и Руби при типизации строже чем в С++ — это не принципиальное решение?

CS>Лично для меня явно определить тип всегда лучше — лишний checkpoint
CS>который отлавливается в compiletime и сразу, а не в runtime.

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

CS>Кстати Вальтер добавил в D auto т.е. такое вот работает:
CS>auto i = 2+2;

Такое и в C# скоро появится. Согласись Нэмерл пошел сильно дальше.

VladD2,

VD> [Learning to fly, версия Влада].

Хоть я и вечный твой оппонент, но положа руку на сердце — рассказ весьма интересный. Респект!

//про десятипальцевый метод — в самую точку!

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

VD>И вот еще что. Заметь! Ты сравнивашь скриптовый язык с языком который по всем параметрам кроме простоты или не уступает, или привосходит С++. А в простоте он его делает как катентка.

Ты так уверен? Сколько кода ты написал на Nemerle чтобы об этом судить?

E>>Об этом сейчас я бы не стал судить. Макросы в Nemerle это отдельная и большая поляна для грабель.

VD>Макросы писать не обязательно. И отлаженный макрос способен вызвать только те грабли которе ты сам лично туда зложил.

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

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

VD>ЗЫ

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

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

1. У тебя вообще образование связано с программированием? Или же ты в большей степени самоучка?

2. Ты так с легкостью переходил с одной технологии на другую... А как быть с проектами, которые развивались в рамках какой-нибудь технологии в течении нескольких лет?

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

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

WF>Если под "боксингом" ты имеешь ввиду полиморфизм (т.е когда в массиве хранится некий Object или т.н "Top"), то ситуация такая. (далее идут мои, возможно ошибочные, размышления). Вообще говоря, можно ввести тип Top, однако в силу статичности O`Caml его смысл несколько теряется (т.к ты все равно с этим типом потом ничего осмысленного не сделаешь).

В Немерле таких проблем нет. Вся динамическая поддержка дотнета в твоем распоряжении.

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

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

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

VD>К тому же ты сам усугубил свою проблему создав неявное приведение к bool.

Я имел в виду:
Вот еще один пример "из жизни" (я его, конечно, схематизировал), связанный с этой стороной Си++.
Приведенный пример связан с моделированием FPU другого процессора.
Код не мой, но ведь часто так и пишут на Си++.
Меня удивило только "равнодушие" компилятора.
Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

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

E>1. У тебя вообще образование связано с программированием? Или же ты в большей степени самоучка?

По образованию я юнист и бухгалтер. Неужели не похоже?

E>2. Ты так с легкостью переходил с одной технологии на другую... А как быть с проектами, которые развивались в рамках какой-нибудь технологии в течении нескольких лет?

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

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

Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. Это я говорю как экономист. Конечно речь не идет о монстрах вроде МС и Сана. Они то могут себе повзолить и деять параллельных продуктов на совершенно разных принципах. Могут позволить себе писать ОС 15 лет подряд на С. У них есть на это деньги.

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

E>Ты так уверен? Сколько кода ты написал на Nemerle чтобы об этом судить?

Зато я таскал мешки с цементом! Это тоже в зачет идет!

VD>>Макросы писать не обязательно. И отлаженный макрос способен вызвать только те грабли которе ты сам лично туда зложил.

E>Классная фраза. Эдак про што угодно сказать можно.

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

E>Макросы отличаются от обычного кода тем, когда и как они запускаются. Можно ли, например, их отладочными печатями проверять?

Легко. Просто вызов вывода в косоль выводится во время компиляции. А вызов заключенный в <[ ]> попадает в генерируемый код. Собственно примеры есть на их сайте.

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

AVC>Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

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

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

E>>1. У тебя вообще образование связано с программированием? Или же ты в большей степени самоучка?

VD>По образованию я юнист и бухгалтер. Неужели не похоже?

Похоже, но лучше знать наверняка
Поросто те вещи, про которые ты написал, даже в нашем провинциальном ВУЗе, даже в далекие 1990-1995 годы, рассказывалось на лекциях преподавателями или на переменках друзьями-коллегами, которые где-то подрабатывали. Была соответствующая атмосфера, в которой информация о старых и новых направлениях буквально витала в воздухе и только ленивый ее не анализировал и не усваивал.

Поэтому то, что для тебя бывало для открытием, для многих было всего лишь информационным фоном. Я не хочу сказать, что для меня никаких откровений не было, отнюдь. Но то, что я спокойнее воспринимал новые открытия, это очень вероятно. Может потому, что изначально этих открытий было больше. Я, например, радовался, когда появился Windows и был стороником Windows, даже агитировал за Windows когда был выбор между Windows и OS/2. Только вот OLE и COM-у я совершенно не обрадовался и всегда старался держаться подальше, так же как и от CORBA. Зато довольно быстро понял, что Java станет серьезным противником C++ и, поэтому, при каждом удобном случае старался провозгласить "Java must die!"

VD>А вообще, все очень просто. Продукт который не выпущен на ранок за 2-3 года рискует оказаться провальным.

Есть системы, рынок которых достаточно узок и малоизвестен. В качестве примеров можно взять системы для банковского процессинга, АСУТП, телекоммуникации. В таких нишах оперативное реагирование на технологии даже каждые пять лет уже не просто. А пять лет -- это не так уж мало. Например, Java появилась в 1995-1996 годах, но тогда она не была конкурентом C++. Через пять лет (в 2000-2001) уже можно было бы инициировать смену платформы с Java на C++, вполне. Но проходит еще пять лет и в качестве весьма серьезной альтернативы Jave выступает C#. А еще через пять лет альтернативой C# вполне может стать Nemerle.
Да вот, если время выпуска версии занимает 2-3 года, то смена мейнстрима раз в пять лет -- это слишком расточительно, имхо.

VladD2,

> А вообще, все очень просто. Продукт который не выпущен на ранок за 2-3 года рискует оказаться провальным. Револющии и темболее эволюции даже в нашей бурно развивающейся индустрии происходят куда реже. Так что можно без проблем сдавать продукт и начинать новый на новом витке.
>
> Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. <...>

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

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

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

[ИМХО]
Влад, ну ведь эрудированный человек, писал на C/С++ и вот все строишь из себя С++ ненавистника.
Зачем ?

С++ это, как минимум, Веха в истории развтития языков программирования, такая как Java ( не C# ибо .Net есть попытка повторения успеха платформенно-независимой машины ).

Ну вот зачемв все так экранизировать ? ( В отношении себя и C++ естественно )
[/ИМХО]

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

Положа руку на сердце — согласен — это все очень хорошо и понятно.

Но как всегда — есть одно НО, а именно — автор кода — легко поймет что скрывается за "визуально не типизированным" выражением, а вот программист, которыёё будет этот код поддерживать ?

Дело в том, что как излишняя типизация есть зло, так и отсутсвие ьтаковой, ИМХО, есть тоже зло, ибо расслабляет программиста и как результат — код в котором тожде трудно понять чот и как с первого взгляда.

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

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

CS>>Еще раз мне представляется проблема несколько надуманной.
CS>>На Java я пишу немного в последнее время. А в C++ автоматический вывод типов
CS>>я из своей практики исключил. И лучше бы его там не было вообще.

WF>Интересно, как можно говорить о некоторой возможности если ты даже с ней не работал (впечатление такое сложилось)?

Я не понял, с чем я не работал? С Nemerle — не работал. С O'Caml — тоже.
C C++ работаю.

WF>..и даже не хочешь узнать, что это за фича и как она работает.

Как она работает я знаю или, скажем так, понимаю как сделать.
Я не понимаю зачем.

WF>В O`Caml disjoint union-ов нет. Но ничто не мешает использовать в данном случае joint union.

А самый завлящщий discriminated union ?
Иногда надо.


CS>>"не ошибаешься в указании типа". Если я ошибусь мне компайлер скажет.
CS>>А в твоем случае скажет unittest. Который еще писать надо.

WF>Нет. Тип выведется. И в худщем варианте, выведется более общий тип, чем ты указал бы.

Я как-то об этом узнаю?

WF>Да, позволяет. Работать с очень сложными типами. Пример — монады (а еще лучше Arrows Хаскелля ). Посмотрел бы я на того маньяка, кто захочет везде явно типы указывать Ты указываешь типы для граничных случаев (там где ввод/вывод, например), а все остальные внутренние сложные типы выводятся автоматически.

"Работать с очень сложными типами" как это связано с длиной
идентификатора типа? Что такое вообще "очень сложный тип" в твоем понимании?

Кроме того что не нужно писать типы явно что-нибудь еще
есть в автоматическом выводе типов?

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

WF>>Интересно, как можно говорить о некоторой возможности если ты даже с ней не работал (впечатление такое сложилось)?

CS>Я не понял, с чем я не работал? С Nemerle — не работал. С O'Caml — тоже.
CS>C C++ работаю.

С выводом типом по типу как в ML-языках.

WF>>..и даже не хочешь узнать, что это за фича и как она работает.

CS>Как она работает я знаю или, скажем так, понимаю как сделать.
CS>Я не понимаю зачем.

Я отвечал зачем. Ниже написал еще раз. Плюс важное замечание

WF>>В O`Caml disjoint union-ов нет. Но ничто не мешает использовать в данном случае joint union.

CS>А самый завлящщий discriminated union ?
CS>Иногда надо.

Ну это join union и есть, насколько я понимаю.

WF>>Нет. Тип выведется. И в худщем варианте, выведется более общий тип, чем ты указал бы.

CS>Я как-то об этом узнаю?

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

CS>"Работать с очень сложными типами" как это связано с длиной
CS>идентификатора типа? Что такое вообще "очень сложный тип" в твоем понимании?

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

В моем понимании "очень сложный тип" — это когда много стрелочек Если в типе употребляется где-то больше 5 других типов, для меня это уже сложно.

Один из способов работы с такими объектами — отказаться от статической типизации (как и делают в скриптовых языках, например). Другой способ — вывод типов.

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

Еще один момент — это параметрический полиморфизм. Допустим, где-то в коде у тебя есть выражение map(func, lst), где map и func — функции, lst — некоторые параметры. Как ты можешь узнать, что это выражение корректно? Что тип элемента списка, сигнатура func и map — консистентны? При том, что map — полиморфная функция, она может работать со множеством разных параметров разных типов. Ты же не будешь к каждому подвыражению приписывать конкретный тип? Например, в случае выражения "map (\x -> x*2) [1, 2, 3]", тип map будет выведен как (int->int)->[int]->[int]. А в случае "map (\x -> x*2) ["1", "2", "3"]" будет ошибка унификации — тип не может быть выведен, т.е выражение неконсистентно.

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

CS>Кроме того что не нужно писать типы явно что-нибудь еще
CS>есть в автоматическом выводе типов?

Написал выше.

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

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

А именно?

IT,

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

> А именно?

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

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

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

>> А именно?

ПК>

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

Мне классиков цитировать не надо Мне интересно знать о каком именно продукте идёт речь?

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

S>Влад, ну ведь эрудированный человек, писал на C/С++ и вот все строишь из себя С++ ненавистника.
S>Зачем ?

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



Я не ненавистник. Я считаю С++ этапом. Этапом в истории, этапом в собственном развитии. И считаю, что этап это пройден. Согласен, что не для всех. Но для меня одноначно пройден.

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

S>Но как всегда — есть одно НО, а именно — автор кода — легко поймет что скрывается за "визуально не типизированным" выражением, а вот программист, которыёё будет этот код поддерживать ?

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

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

S>Дело в том, что как излишняя типизация есть зло, так и отсутсвие ьтаковой,

Это не отсуствие! В этом вся и разница.

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

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

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

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

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

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

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

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



Д>Так что я не вижу ни малейших проблем в том, чтобы использовать новые технологии в новых подсистемах,

Например, механизмы коммуникаций между старыми подсистемами.

Д>или переписывать с их помощью особо проблематичные старые подсистемы.

А что, старые подсистемы по-определению проблематичные и нуждаются в переписывании?
Мне представляется, что долгоиграющий продукт с проблематичными подсистемами просто не выжил бы.

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

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

IT>А именно?

А можно мне за Павла ответить? Ну, например, Base24-card.

Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

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

E>Например, механизмы коммуникаций между старыми подсистемами.

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

Д>>или переписывать с их помощью особо проблематичные старые подсистемы.

E>А что, старые подсистемы по-определению проблематичные и нуждаются в переписывании?

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

E>Мне представляется, что долгоиграющий продукт с проблематичными подсистемами просто не выжил бы.

Это предположение, или точные данные?

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

Д>Это станет проблемой только в том случае, если механизм не продумывался заранее. (см пункт про битье по рукам)

Архитектура изначально могла не расчитываться на интероперабельность с системами на других языках. Например, могло использоваться что-то, что хорошо работало в рамках одного языка. Скажем, собственный протокол на основе коммуникационных возможностей OS. Десять лет назад никто не использовал, скажем, XML-RPC или SOAP для взаимодействия компонентов.

Д>именно так. Чем больше возраст кода, тем больше там "заплаток", подпорок, и просто ненужного кода. Рано или поздно любой модуль приходится переписывать. Всё, что нужно для этого — нормальная документация, которая подробно описывает интерфейс модуля и функционал.

Это предположение или точные данные?

E>>Мне представляется, что долгоиграющий продукт с проблематичными подсистемами просто не выжил бы.

Д>Это предположение, или точные данные?

Э... экстраполяция собственного не очень большого опыта. Наверное точно выразился.

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

E>А можно мне за Павла ответить? Ну, например, Base24-card.

А вот не надо за Павла отвечать

E>Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

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

ЗЫ. И вообще, студия наполовину на шарпе написана.

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

IT>А вот не надо за Павла отвечать



E>>Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

IT>Я не понимаю таких аргументов. Точнее понимаю только из уст тех кто написал эти продукты. Иначе получается фигня, а не аргумент — раз студия на плюсах написана, значит и мы свой склад бракованных изделий тоже будем на плюсах писать

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

Вообще, складывается впечатление, что C# гарантирует отличный и безглючный софт. А вот C++ -- 100% гарантия обратного эффекта. Ну не бывает так.

IT>ЗЫ. И вообще, студия наполовину на шарпе написана.

Ничего удивительного, она же должна и шарп поддерживать.

IT wrote:
> ЗЫ. И вообще, студия наполовину на шарпе написана.
Там на Шарпе только мелкие и сравнительно автономные вещи типа панелей
свойств.

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

E>Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

Ну, вот возми к примеру Visual Studio. 5.0 и 6.0 — это два разных продукта. Очень разных! Так что совершенно не важно на чем они писались.

6.0 и 7.х (2003) тоже совершенно разные продукты. В 7.х не малый объем кода написан на C#. В 2005-ой студии объем дотнетного кода еще более увеличился, хотя она как раз является развитием 2003-ей.

Уже известно, что в будущем студия будет переписана целиком на нотнете...

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

VD>Ну, вот возми к примеру Visual Studio. 5.0 и 6.0 — это два разных продукта. Очень разных! Так что совершенно не важно на чем они писались.

VD>6.0 и 7.х (2003) тоже совершенно разные продукты. В 7.х не малый объем кода написан на C#. В 2005-ой студии объем дотнетного кода еще более увеличился, хотя она как раз является развитием 2003-ей.

Вообще-то VS оказалась не удачным примером. Она слишком сильно на языки и технологии программирования завязана.

VD>Уже известно, что в будущем студия будет переписана целиком на нотнете...

Главное, что следующая версия gvim не будет переписана на дотнете

Здравствуйте, AVC, Вы писали:
.
AVC>Меня удивило только "равнодушие" компилятора.
AVC>Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

Вся беседа в целом кое-что мне напоминает. А именно — реакцию лордов на изобретение первого паровоза. Один опасался, что красный цвет трубы паровоза (греется до красна) будет нервировать стада коров, пасущихся рядом с трассой, и предлагал на всякий случай запретить паровоз. А второй — думал, что есть такая опасность, что паровоз не поедет — колеса-то в той или иной степени гладкие и скользкие, как и рельсы. И предлагал сделать колеса зубчатыми. Штоб цеплялись.

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

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

VD>Уже известно, что в будущем студия будет переписана целиком на нотнете...

Откуда дровишки? Я не слышал о планах переписывать; слышал о планах переносить. Т.е. значительные куски кода собирались оставить теми же, но перекомпилировать в режиме C++/CLI.

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

WF>>..и даже не хочешь узнать, что это за фича и как она работает.

CS>Как она работает я знаю или, скажем так, понимаю как сделать.
CS>Я не понимаю зачем.

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

Возьми шаблонную функцию С++. Типы ее аргументов не выводятся, они проверяются при инстанцировании в каждом конкретном случае. Теперь предствь, что компилятор может вывести параметризованный тип из контекста употребления для любой функции, и тебе не надо писать template. Так что любая функция у тебя обладает параметрическим полиморфизмом без лишних теложвижений с твоей стороны. Вот зачем в языках группы ML делается вывод типов. А зачем это делает Немерле — не знаю. Если за этим самым — то хорошо.

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

ПК>Откуда дровишки?

От тех кто говорил с ее разработчиками.

ПК> Я не слышал о планах переписывать; слышал о планах переносить. Т.е. значительные куски кода собирались оставить теми же, но перекомпилировать в режиме C++/CLI.

Я рад за то, что ты понимаешь, что не мог слышать все на свете.

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

E>Вообще, складывается впечатление, что C# гарантирует отличный и безглючный софт. А вот C++ -- 100% гарантия обратного эффекта. Ну не бывает так.

Заметьте! Не я это первый сказал!

Речь не о глючном / безглючном. Выше по ветке Паша делает весьма смелое заявление:

> Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. <...>

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

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

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

>> ЗЫ. И вообще, студия наполовину на шарпе написана.
C>Там на Шарпе только мелкие и сравнительно автономные вещи типа панелей свойств.

А Microsoft.VSDesigner namespace — это, по-твоему, недоразумение?

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

E>Архитектура изначально могла не расчитываться на интероперабельность с системами на других языках. Например, могло использоваться что-то, что хорошо работало в рамках одного языка. Скажем, собственный протокол на основе коммуникационных возможностей OS. Десять лет назад никто не использовал, скажем, XML-RPC или SOAP для взаимодействия компонентов.

XML в данном случае — это худший выбор из всех возможных. Есть очень много куда более легковесных технологий — C-api, COM и аналоги, командная строка, MMF, пайпы, сокеты и т.д. и т.п.

E>Это предположение или точные данные?

это как раз точные данные

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

IT>

>> Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. <...>

IT>Эти рассуждения обычно неприменимы к продукту с долгим временем жизни.

IT>Вот мне и интересно, какой именно продукт Паша имеет ввиду, т.к. у меня на этот счёт совсем другое мнение. И заключается оно в том, что чем дольше время жизни проекта, тем раньше надо переходить на новые технологии.

Я говорил о продуктах, которые уже достаточно долго живут, но очередные релизы которых, тем не менее, должны регулярно выходить. Примеры eao197 привел. Могу и я сколько-то добавить (например, см. ссылку в моем профайле на MetaCommunications, там products), но что это поменяет?

P.S.

ПК>Я говорил о продуктах, которые уже достаточно долго живут, но очередные релизы которых, тем не менее, должны регулярно выходить. Примеры eao197 привел.

Кстати, примеры на продукты больших компаний далеко не так показательны, т.к. большая компания легче, чем маленькая, может позволить себе выпускать продукты с заметно меньшей регулярностью. Маленькая компания без выпуска очередных версий (*) в течение пары лет "загнется" наверняка.

(*) Или новых продуктов, но мы-то о маленьких компаниях, выпускающих большие долгоиграющие продукты, коих много не сделаешь...

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

ПК>Я говорил о продуктах, которые уже достаточно долго живут, но очередные релизы которых, тем не менее, должны регулярно выходить. Примеры eao197 привел. Могу и я сколько-то добавить (например, см. ссылку в моем профайле на MetaCommunications, там products), но что это поменяет?

Вы же сами потихоньку мигрируете, по-крайней мере штамп .NET на двух продуктах я увидел

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

ПК>> Примеры eao197 привел. Могу и я сколько-то добавить (например, см. ссылку в моем профайле на MetaCommunications, там products), но что это поменяет?

IT> Вы же сами потихоньку мигрируете, по-крайней мере штамп .NET на двух продуктах я увидел

.NET используется только для Web. В продукт входит N приложений, в т.ч. и Web, вот штамп и стоит...

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

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

ПК>.NET используется только для Web. В продукт входит N приложений, в т.ч. и Web, вот штамп и стоит...

Ну так с веба обычно всё плохое и начинается Сначала веб, потом серверок на .NET перепишите, а там и юайщики подтянутся

Hello, "IT"

>>> ЗЫ. И вообще, студия наполовину на шарпе написана.
> C>Там на Шарпе только мелкие и сравнительно автономные вещи типа панелей свойств.
>
> А Microsoft.VSDesigner namespace — это, по-твоему, недоразумение?

Еще скажи, что в System.Data.dll это компилятор C# создал namespace <CppImplementationDetails> и namespace <CrtImplementationDetails>

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

G>Здравствуйте, c-smile, Вы писали:

WF>>>..и даже не хочешь узнать, что это за фича и как она работает.

CS>>Как она работает я знаю или, скажем так, понимаю как сделать.
CS>>Я не понимаю зачем.

G>Затем же, зачем в С++ есть шаблоны. Делается это для того, чтобы компилятор вывел общий тип.

G>Возьми шаблонную функцию С++. Типы ее аргументов не выводятся, они проверяются при инстанцировании в каждом конкретном случае.

Да ну? Ты ничего не перепутал?

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

Всё -- шаблон -- это плохая идея. Например потому, что при выводе типов шаблонов функций не работают неявные конверсии типов.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

G>>Здравствуйте, c-smile, Вы писали:

WF>>>>..и даже не хочешь узнать, что это за фича и как она работает.

CS>>>Как она работает я знаю или, скажем так, понимаю как сделать.
CS>>>Я не понимаю зачем.

G>>Затем же, зачем в С++ есть шаблоны. Делается это для того, чтобы компилятор вывел общий тип.

G>>Возьми шаблонную функцию С++. Типы ее аргументов не выводятся, они проверяются при инстанцировании в каждом конкретном случае.

Ш>Да ну? Ты ничего не перепутал?
Ну да. Я — ничего не перепутал. Еще что-нибудь сказать есть, кроме междометий?

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

Ш>Всё -- шаблон -- это плохая идея. Например потому, что при выводе типов шаблонов функций не работают неявные конверсии типов.

Это не идея. Это я на яблоках, прибегая к аналогиям, объясняюю, на что похож вывод типов в языках с системой Хиндли-Милнера. С расчетом на то, что до знающего С++ человека дойдет, зачем это надо. А ты все перепутал. В любом случае — если так не понятно, значит уже не вдолбить никак. По крайней мере, у меня идей больше нет, как объяснить.

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

AVC>>Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

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

AFAIK, в 90-х Ритчи создал язык Limbo (для системы Inferno ).
Использовать Си++ он "почему-то" не стал.
Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора, модульность, может использоваться на машинах без memory-protection...
Ну прямо как Обе...
Впрочем, ой, что это я! На RSDN же полагается верить, что именно Вирт завидует успехам Ритчи и Страуструпа...

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

AVC>AFAIK, в 90-х Ритчи создал язык Limbo (для системы Inferno ).
AVC>Использовать Си++ он "почему-то" не стал.
AVC>Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора, модульность, может использоваться на машинах без memory-protection...
AVC>Ну прямо как Обе...

как странно, в слове "Лисп" совсем нет таких букв

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

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

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

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

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

VD>Хм. Нэмерл выводит типы. Это всеравно что вписывать их явно. Так что ошибок быть не может. Язык статически типизированный!

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

AVC wrote:
> Использовать Си++ он "почему-то" не стал.
Тогда С++ еще был "в детстве", так что неудивительно.

> Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора,
> модульность, может использоваться на машинах без memory-protection...
Там не сборка мусора, а подсчет ссылок. С++ тоже замечательно
используется без защиты памяти.

Из от С++ отличных фич Limbo и системы Inferno: поддержка параллелизма и
распределенности на уровне языка (в виде каналов), более сильная
типизация, другой синтаксис, динамическая подгрузка кода. В начале 90-х
это было вполне приличным набором.

Однако, современный С++ большую часть фич Limbo реализует в виде библиотек.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Думается мне, что eao197 говорил про то, как ты полезешь как-нибудь в исходники, которые ты писал год-полтора назад, и увидишь такую вот безличную картину.
СТ>Как, без поддержки IDE, ты вспомнишь, кто что возвращает?
Обычно типы можно посмотреть безо всяких IDE, достаточно интерпретатора.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Думается мне, что eao197 говорил про то, как ты полезешь как-нибудь в исходники, которые ты писал год-полтора назад, и увидишь такую вот безличную картину.

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

std::map< std::string, std::map< std::string, int > > build_report( const report_params_t & params );

Вроде и типы все знаешь, а что это такое и почему -- вопрос.

Но я действительно упустил из виду, что в Nemerle все, что идет из метода наружу, должно декларироваться.

СТ>Как, без поддержки IDE, ты вспомнишь, кто что возвращает?

Применительно к Nemerle меня больше всего забавляет другое -- вроде бы и язык интересный, и многое обещает, и многим нравится. Но препятствием служит отсутствие IDE!
По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.

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

PA>Обычно типы можно посмотреть безо всяких IDE, достаточно интерпретатора.

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

Если же речь идет о статически типизированных языках, т.к. C++ (Java, C#), то для просмотра типа тебе достаточно иметь заголовочные файлы.

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


E>Да, именно об этом. Причем, как показала практика, забывается все уже буквально через пару дней
E>В статически типизированных языка так же можно устроить себе подобные приключения, если, например, написать:
Языки с автоматическим выводом типов — статически типизируемые, попрошу не путать .
E>

E>std::map< std::string, std::map< std::string, int > > build_report( const report_params_t & params );
E>

E>Вроде и типы все знаешь, а что это такое и почему -- вопрос.
ПО-моему, функция построения отчета по каким-то параметрам (кстати, это целая проблема — придумывать названия параметрам типа args, settings, options, params,...).

E>Применительно к Nemerle меня больше всего забавляет другое -- вроде бы и язык интересный, и многое обещает, и многим нравится. Но препятствием служит отсутствие IDE!
На IDE внимание акцентирует только Влад, не надо обобщать.
E>По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.
Намекнуть, чем пользуются программисты на Лиспе, ML, Erlang, ...?

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

PA>Языки с автоматическим выводом типов — статически типизируемые, попрошу не путать .

Я и не путаю
Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python. Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения. Но на момент написания кода подсказок-то нет (разве что IDE будет очень умная).

PA>ПО-моему, функция построения отчета по каким-то параметрам (кстати, это целая проблема — придумывать названия параметрам типа args, settings, options, params,...).

Ага, вопрос в том, что является ключем в первом map (имя клиента или имя сервиса), а что во вложенном (имя сервиса или имя клиента).

PA>На IDE внимание акцентирует только Влад, не надо обобщать.

Не только

Автор: Максим Зелинский
Дата: 08.02.06

PA>Намекнуть, чем пользуются программисты на Лиспе, ML, Erlang, ...?

Думаю, что emacs-ом, но неужели VisualStudio?

Отвечу в обратном порядке.

E>Если же речь идет о статически типизированных языках, т.к. C++ (Java, C#), то для просмотра типа тебе достаточно иметь заголовочные файлы.
Статически типизируемые языки — это те, в которых типы известны на этапе компиляции, соответственно компилятор дает по рукам при ошибках типизации. Независимо от того, выводятся типы автоматически или вбиваются вручную.

E>Чтобы посмотреть типы в run-time, необходимо, как минимум, работающее окружение. Т.е. некий тестовый стенд, на котором ты можешь запустить тестовый прогон и поставить точку прерывания в нужном месте.

Да нету никаких рантаймов, тестовых прогонов и точек прерывания.
На примере ОКамла.
Разработка ведется в стиле REPL. В процессе разработки нового модуля периодически скармливаем текст интерпретатору. И тут же видим типы всех значений (в т.ч. функций), определенных в модуле. Во время активной разработки достаточно ml-файла (некий аналог .cpp-файла) — т.к. есть вывод типов, то и интерфейс модуля выводится автоматически. Затем, после того, как модуль устаканится, можно добавить mli-файл, в котором явно указываются все экспортируемые значения и их типы.

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

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

AVC>>Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора, модульность, может использоваться на машинах без memory-protection...
AVC>>Ну прямо как Обе...

Д>как странно, в слове "Лисп" совсем нет таких букв

Кроме того, Limbo — императивный язык...

"Человек — двуногое существо без перьев и с плоскими ногтями." (c) Платон

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

PA>На примере ОКамла.
Вот, тебе, как разработчику build-системы, может быть интересна работа конкурентов:
http://svn.metaprl.org/viewcvs/mojave/omake/src/
Думаю, в .mli-файлах все понятно, без интерпретатора, что опровергает тезис о невозможности понять что-либо в программах на языках с выводом типов без IDE . С другой стороны, если ты сопровождаешь систему, то компилятор и интерпретатор таки должны быть под рукой.

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

E>>Если же речь идет о статически типизированных языках, т.к. C++ (Java, C#), то для просмотра типа тебе достаточно иметь заголовочные файлы.
PA>Статически типизируемые языки — это те, в которых типы известны на этапе компиляции, соответственно компилятор дает по рукам при ошибках типизации. Независимо от того, выводятся типы автоматически или вбиваются вручную.

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

E>>Чтобы посмотреть типы в run-time, необходимо, как минимум, работающее окружение. Т.е. некий тестовый стенд, на котором ты можешь запустить тестовый прогон и поставить точку прерывания в нужном месте.

PA>Да нету никаких рантаймов, тестовых прогонов и точек прерывания.

Ок. Методику работы понял.

PA>Еше раз — отсутствие фич (в данном случае вывода типов) нельзя выдавать за преимущество. Если пугает опасность забыть типы функций в модуле — всегда есть возможность добавить аннотации типов. Но языки, которые требуют вводить типы на каждом шагу, как справку из ЖЭКа, морально устарели.

Может быть (хотя я пока так не думаю).
Но вот если взглянуть с другой стороны:

std::auto_ptr< io_controller_t > c = make_io_controller( params );
c->flush_all();

Ведь здесь есть факт двойного соглашения -- с одной стороны, make_io_controller обязуется отдать мне объект, который может быть приведен к std::auto_ptr<io_controller_t>. С другой стороны, я явно объявляю, что в этом месте мне нужен именно std::auto_ptr<io_controller_t>, а не что-нибудь другое. Поэтому компилятор бьет меня по рукам при нарушении соглашения с любой из сторон.
Если бы у меня была конструкция:

auto c = make_io_controller( params );
c->flush_all();

то при смене типа возвращаемого значения у make_io_controller я об этом даже не узнаю -- компилятор просто сделает c нужного типа и все.
Например, такой сценарий: make_io_controller стал возвращать не auto_ptr, а io_controller_t*. Если мой код об этом не узнает, то я не буду удалять объекты io_controller_t.

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

E>Но вот если взглянуть с другой стороны:
E>

E>std::auto_ptr< io_controller_t > c = make_io_controller( params );
c->>flush_all();
E>

E>Ведь здесь есть факт двойного соглашения -- с одной стороны, make_io_controller обязуется отдать мне объект, который может быть приведен к std::auto_ptr<io_controller_t>. С другой стороны, я явно объявляю, что в этом месте мне нужен именно std::auto_ptr<io_controller_t>, а не что-нибудь другое. Поэтому компилятор бьет меня по рукам при нарушении соглашения с любой из сторон.
E>Если бы у меня была конструкция:
E>

E>auto c = make_io_controller( params );
c->>flush_all();
E>

E>то при смене типа возвращаемого значения у make_io_controller я об этом даже не узнаю -- компилятор просто сделает c нужного типа и все.
E>Например, такой сценарий: make_io_controller стал возвращать не auto_ptr, а io_controller_t*. Если мой код об этом не узнает, то я не буду удалять объекты io_controller_t.
Это особенности C++. Попробуй придумать пример, не связанный с ручным управлением памятью и приведением типов .

Если серьезно, вернемся к классическим определениям. АТД определяется множеством операций, которые над ним можно выполнять. flush_all и есть такая операция. Поэтому менять тип make_io_controller как угодно не удастся.

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

PA>Это особенности C++. Попробуй придумать пример, не связанный с ручным управлением памятью и приведением типов .

Приведение типов как раз возможно в языках со сборкой мусора, например, множественное наследование интерфейсов.

PA>Если серьезно, вернемся к классическим определениям. АТД определяется множеством операций, которые над ним можно выполнять. flush_all и есть такая операция. Поэтому менять тип make_io_controller как угодно не удастся.

А тебе не кажется, что это уже duck typing начинается?
Т.е., если я сменю тип возвращаемого значения на другой, в котором есть метод flush_all (возможно случайно), то все нормально?

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

E>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python. Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения. Но на момент написания кода подсказок-то нет (разве что IDE будет очень умная).

Как мне думается, особых мозгов от IDE это не потребует, так как все равно придется пользовать компилятор как библиотеку.
Но ведь есть еще и макросы, меняющие синтаксис. Вот тут надо будет много думать.

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

E>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python.
Ключевое — визуально. Разница существенная.
E>Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения.
Этого недостаточно?
По-моему, до появления generic'ов в дотнете и яве это был один из очень сильных аргументов в пользу STL против соответствующих библиотек дотнета и явы.
В C++ вообще очень любят как можно больше делать на этапе компиляции, и это правильно — вспомним CT-assert'ы, concept check libraries и т.д. Ты сам это прекрасно знаешь, не лукавь .
E>Но на момент написания кода подсказок-то нет (разве что IDE будет очень умная).
Для качественных подсказок IDE должна выполнять львиную долю работы компилятора или быть с компилятором интегрирована, и в данном случае ничего не меняется. Когда я использую злые шаблоны с частичными специализациями, вложенные типы и пространства имен, я тоже часто остаюсь без подсказки.

PA>>На IDE внимание акцентирует только Влад, не надо обобщать.
E>Не только

Автор: Максим Зелинский
Дата: 08.02.06

Это особенность Windows-developer'ов, которые (включая меня) давно сидят на игле ИДЕ. Т.к. Немерле позиционируется как замена Шарпу, целевая аудитория у него такая — привыкшая к Студии, это не хорошо и не плохо, это факт. Вон Vermicious Knid, с другой стороны, пишет и не жалуется, получается как-будто здорово. Так что как аргумент против Немерла и вывода типов это не проходит.

PA>>Намекнуть, чем пользуются программисты на Лиспе, ML, Erlang, ...?
E>Думаю, что emacs-ом, но неужели VisualStudio?
Угадал !

eao197 wrote:
> А тебе не кажется, что это уже duck typing начинается?
> Т.е., если я сменю тип возвращаемого значения на другой, в котором есть
> метод flush_all (возможно случайно), то все нормально?
А тут нам помогут концепты

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

E>>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python.
PA>Ключевое — визуально. Разница существенная.

Когда я пишу код, мне важно именно "визуальная" составляющая -- то, что мне видно в исходниках/документации.

E>>Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения.
PA>Этого недостаточно?

Достаточно для чего?
Чтобы совершить ошибку в коде и написать не правильное формирование тела отчета? Код уже написан. Вот что главное. И если мне компилятор скажет, что код не правильный, мне его придется переписывать точно так же, как если об ошибке сообщит unit-test.

PA>>Это особенности C++. Попробуй придумать пример, не связанный с ручным управлением памятью и приведением типов .
E>Приведение типов как раз возможно в языках со сборкой мусора, например, множественное наследование интерфейсов.
При множественном наследовании интерфейсов ситуация (утечка памяти из-за неправильного объявления типа), которую ты описал в примере, невозможна. Во-вторых, языки со сборкой мусора!=Java. В-третьих, мы говорили о возможных опасностях вывода типов. Жду другого примера .

PA>>Если серьезно, вернемся к классическим определениям. АТД определяется множеством операций, которые над ним можно выполнять. flush_all и есть такая операция. Поэтому менять тип make_io_controller как угодно не удастся.
E>А тебе не кажется, что это уже duck typing начинается?
Я предпочитаю теримн generic programming (как мне кажется, об утиной типизации только ruby-сообщество говорит).
E>Т.е., если я сменю тип возвращаемого значения на другой, в котором есть метод flush_all (возможно случайно), то все нормально?
Если это ненормально, добавляем тип вручную. Если нормально, оставляем обобщенную реализацию и позволяем компилятору сделать грязную работу. Все просто .

Здравствуйте, Сергей Туленцев, Вы писали:

Мы там тебе письма посылали. Ответь, плиз.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Думается мне, что eao197 говорил про то, как ты полезешь как-нибудь в исходники, которые ты писал год-полтора назад, и увидишь такую вот безличную картину.
СТ>Как, без поддержки IDE, ты вспомнишь, кто что возвращает?

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

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

E>>>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python.
PA>>Ключевое — визуально. Разница существенная.
E>Когда я пишу код, мне важно именно "визуальная" составляющая -- то, что мне видно в исходниках/документации.
В исходниках и документации содержится ровно то, что мы туда вносим. Если мы хотим там что-от видеть — мы беремся за клавиатуру и принимаемся стучать(еще раз рекомендую посмотреть на описания интерфейсов модулей в реальной программе на O'Caml). Но мы, труженики клавы и монитора, лучше других должны понимать, что наши любимые компьютеры служат для автоматизации рутинных действий и для повышения производительности нашего труда за счет освобождения мозгов для творческой работы. Если я пишу простую функцию вроде

let rec member list x =
    match list with
    []         -> false
    head::tail -> if head=x then true 
                                else member tail x;;

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

PA>>Этого недостаточно?
E>Достаточно для чего?
E>Чтобы совершить ошибку в коде и написать не правильное формирование тела отчета?
Я не знаю, о каких ошибках ты говоришь, и как они связаны именно с выводом типов. Не хочу флеймить по этому поводу, это похоже именно на боязнь паровозов, о которой писал Гапертон.

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

PA>При множественном наследовании интерфейсов ситуация (утечка памяти из-за неправильного объявления типа), которую ты описал в примере, невозможна.

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

PA> Во-вторых, языки со сборкой мусора!=Java.

А разве в C# нет множественного наследования интерфейсов?

PA> В-третьих, мы говорили о возможных опасностях вывода типов. Жду другого примера .

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

E>>А тебе не кажется, что это уже duck typing начинается?
PA>Я предпочитаю теримн generic programming (как мне кажется, об утиной типизации только ruby-сообщество говорит).

Не только, такой же duck typing и в Python-е доступен.

E>>Т.е., если я сменю тип возвращаемого значения на другой, в котором есть метод flush_all (возможно случайно), то все нормально?
PA>Если это ненормально, добавляем тип вручную.

Вот смысл в том, что ненормальность определится не в момент компиляции, а во время unit-тестов.

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

Пример из кода который пишу прямо сейчас:

        static Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> _fontMap = 
            new Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>(
            new ZoomedFontKey.ZoomedFontKeyComparer());

Хотел было описать Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> в юсинге, да не тут то было. ZoomedFontKey — это вложенный приватный класс и за пределами ZoomedFont его не видно. Если бы вывод типов позволил бы мне хотя бы не писать "Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>" два раза, я уже был бы рад.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Как мне думается, особых мозгов от IDE это не потребует, так как все равно придется пользовать компилятор как библиотеку.
СТ>Но ведь есть еще и макросы, меняющие синтаксис. Вот тут надо будет много думать.

Дык жто же этот самый компилятор не сможет с макросами разобраться?

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

PA>(еще раз рекомендую посмотреть на описания интерфейсов модулей в реальной программе на O'Caml).

Посмотрел, похоже на h-файлы. Если это автоматом генерируется, то классно.

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

В таком примере — да. Да только не часто лично мне приходится абстрактными списками оперировать. А вот чем-то подобным:

template< class IPC_SAP >
so_4::ret_code_t
make_ipc_controller_pair(
    ipc_sap_owner_templ_t< IPC_SAP > ipc,
    so_4::rt::comm::io_alerter_auto_ptr_t io_alerter,
    ipc_controller_pair_t< IPC_SAP > & pair )
    {
        IPC_SAP * ipc_raw_ptr = ipc.get();

        ipc_sap_owner_auto_ptr_t ipc_owner(
                make_ipc_sap_owner_auto_ptr( ipc ) );
        event_handler_controller_auto_ptr_t controller;

        so_4::ret_code_t result = make_event_handler_controller(
                ipc_owner,
                io_alerter,
                controller );
        if( 0 == result )
            {
                ipc_controller_pair_t< IPC_SAP > p( ipc_raw_ptr, controller );
                pair = p;
            }

        return result;
    }

чуть ли не каждый день.

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

Ошибка была простая -- возвращался Hash, где ключем было имя клиента, а значением -- другой Hash, в котором ключем было имя услуги, а значением -- количество транзакций. Поскольку ключи везде String-и, то я, перепутав, написал вывод отчета, который считал, что в первом хэше ключем является имя услуги, а во вложенных хешах -- имя клиента. Соответственно, не так считалось общее количество транзакций по клиенту. А все из-за того, что лень было тип сделать -- Report и методы getter-ы для него.

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

VD>

VD>        static Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> _fontMap = 
VD>            new Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>(
VD>            new ZoomedFontKey.ZoomedFontKeyComparer());
VD>

VD>Хотел было описать Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> в юсинге, да не тут то было. ZoomedFontKey — это вложенный приватный класс и за пределами ZoomedFont его не видно. Если бы вывод типов позволил бы мне хотя бы не писать "Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>" два раза, я уже был бы рад.

Языками нормальными нужно пользоваться:

typedef Dictionary< ZoomedFont::ZoomedFontKey, ZoomedFont > Dict;
static Dict _fontMap = new Dict( new ZoomedFontKey::ZoomedFontKeyComparer() );

VladD2 wrote:
> Хотел было описать Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> в
> юсинге, да не тут то было. ZoomedFontKey — это вложенный приватный класс
> и за пределами ZoomedFont его не видно. Если бы вывод типов позволил бы
> мне хотя бы не писать "Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>"
> два раза, я уже был бы рад.
Вам бы помогли typedef'ы

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


G>Ну да. Я — ничего не перепутал. Еще что-нибудь сказать есть, кроме междометий?

Есть -- вообще-то в С++ при вызове шаблона функции поисходит вывод типа. Лет уже 15 как.

G>Это не идея. Это я на яблоках, прибегая к аналогиям, объясняюю, на что похож вывод типов в языках с системой Хиндли-Милнера. С расчетом на то, что до знающего С++ человека дойдет, зачем это надо. А ты все перепутал. В любом случае — если так не понятно, значит уже не вдолбить никак. По крайней мере, у меня идей больше нет, как объяснить.

Хамить не надо. Не умеешь объяснять доходчиво свои мысли -- лучше не пиши ничего.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

VD>Здравствуйте, Сергей Туленцев, Вы писали:

СТ>>Думается мне, что eao197 говорил про то, как ты полезешь как-нибудь в исходники, которые ты писал год-полтора назад, и увидишь такую вот безличную картину.
СТ>>Как, без поддержки IDE, ты вспомнишь, кто что возвращает?

VD>Сдается мне, что из кода и так все очевидно. Мне не нужно никаких других подсказок кроме знания о том, что int.Parse преобразует строку в число. Остальное мой мозг выведет все автоматически лучше любого компилятора. Ну, а в местах где это не так очевидно имеет смысл явно указать тип рпи объявлении переменной.

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

using(def x = SomeClass())
{
}

Раньше же приходилось писать так:

def x = SomeClass();
using(x)
{
}

Интересно, это оператор присваивания теперь возвращает значение? Или просто сделали исключение для юзинга. Пойду в исходниках посмотрю.

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

VD>Здравствуйте, Сергей Туленцев, Вы писали:

СТ>>Как мне думается, особых мозгов от IDE это не потребует, так как все равно придется пользовать компилятор как библиотеку.
СТ>>Но ведь есть еще и макросы, меняющие синтаксис. Вот тут надо будет много думать.

VD>Дык жто же этот самый компилятор не сможет с макросами разобраться?

Дык, я не про то. Вот есть у тебя макрос while. Ну или поядреней — using.
Ты видишь using, а после прохода компилятором по этому месту там совершенно другой код.
А IDE, чтобы правильно и по месту показывать ошибки должна как-то с этим разбираться.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Интересно, это оператор присваивания теперь возвращает значение? Или просто сделали исключение для юзинга. Пойду в исходниках посмотрю.

Нет ничего криминального в том, что этот оператор возвращает значение. Источником проблем является тот факт, что некоторые (не будем показывать пальцем ) языки неявно приводят к bool все что под руку попадется.

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

>> А Microsoft.VSDesigner namespace — это, по-твоему, недоразумение?

TK>Еще скажи, что в System.Data.dll это компилятор C# создал namespace <CppImplementationDetails> и namespace <CrtImplementationDetails>

Какая разница? До тех пор пока это на .NET это может быть хоть C#, хоть C++/CLI, хоть его предок-уродец MC++. У нас тут как всегда началось всё с одного, съехало на другое, а аргументы про третье.

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

E>Здравствуйте, Programmierer AG, Вы писали:

PA>>(еще раз рекомендую посмотреть на описания интерфейсов модулей в реальной программе на O'Caml).
E>Посмотрел, похоже на h-файлы. Если это автоматом генерируется, то классно.
Акцент был на то, что если хочется иметь код, документирующий интерфейс модуля, его можно создать, но это не является обязательным. Получить автоматически интерфейс из реализации — раз плюнуть, только после этого его обычно редактируют, чтобы убрать лишние детали реализации (служебные функции, определения типов, которые мы хотим спрятать, и т.д.) и добавить комментарии. Если бы он совсем автоматом генерировался, смысла бы в нем не было.

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

E>А вот чем-то подобным:
А теперь помечтаем, и удалим все лишнее, не теряя типобезопасности:

make_ipc_controller_pair(
    ipc,
    io_alerter,
    out pair )
    {
        ipc_owner = make_ipc_sap_owner( ipc );
        controller = make_controller();

        result = make_event_handler_controller(
                ipc_owner,
                io_alerter,
                controller );
        if( result==0 )
            {
                pair = make_ipc_controller_pair( ipc, controller );
            }
        return result;
    }

Красота!!
Неужели не согласен, что твоя функция пугает не потому, что она такая "системная", а потому, что все типы (с длинными "системными" именами) введены вручную?

E>Ошибка была простая -- возвращался Hash, где ключем было имя клиента, а значением -- другой Hash, в котором ключем было имя услуги, а значением -- количество транзакций. Поскольку ключи везде String-и, то я, перепутав, написал вывод отчета, который считал, что в первом хэше ключем является имя услуги, а во вложенных хешах -- имя клиента. Соответственно, не так считалось общее количество транзакций по клиенту. А все из-за того, что лень было тип сделать -- Report и методы getter-ы для него.
Т.е. грубо говоря, передали сантиметры вместо килограммов, когда и сантиметры, и килограммы были представлены значениями типа float. Если ты знаешь язык, который выявляет такие ошибки, дай знать . К выводу типов это отношения не имеет — ты эту ошибку получил без вывода типов.

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

Д>Здравствуйте, Сергей Туленцев, Вы писали:

СТ>>Интересно, это оператор присваивания теперь возвращает значение? Или просто сделали исключение для юзинга. Пойду в исходниках посмотрю.

Д>Нет ничего криминального в том, что этот оператор возвращает значение. Источником проблем является тот факт, что некоторые (не будем показывать пальцем ) языки неявно приводят к bool все что под руку попадется.

Я так удивился потому, что раньше прочитал в документации, что оператор присвоения возвращает void, равно как и инкремент/декремент.
Стало быть, нельзя писать конструкций вида:

a = b = c;
d = ++e;

Зачем оно так было сделано — не знаю (особенно, если неявного приведения к bool нет), но верю, что были причины.

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

AVC>Кроме того, Limbo — императивный язык...

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

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

PA>А теперь помечтаем, и удалим все лишнее, не теряя типобезопасности:
<... красивый (без иронии) код поскипан ...>
PA>Красота!!

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

В общем, либо я не привык, либо я не пробовал
(кстати, за красоту всегда приходится расплачиваться, чем в данном случае?).

PA>Т.е. грубо говоря, передали сантиметры вместо килограммов, когда и сантиметры, и килограммы были представлены значениями типа float. Если ты знаешь язык, который выявляет такие ошибки, дай знать . К выводу типов это отношения не имеет — ты эту ошибку получил без вывода типов.

Если мне не отшибает память, в Modula-2 и Ada, а так же D, можно было назначать псевдонимы именам типов (вводить подтипы). При этом подтипы дальше существовали как отдельные типы, их нельзя было просто так смешивать с другими типами. Что-то вроде:

typedef string ClientName;
typedef string ServiceName;
typedef int TrxCount;

hash< ClientName, hash< ServiceName, TrxCount > > build_report( ReportParams params );

Все. Просто и надежно.

На эту тему я был в свое время свидетелем многочасового поиска бага в Java-коде, где метод получал несколько строковых аргументов:

public DBConnection getConnection( string dbName, string userName, string password ) { ... };

так вот оказалось, что везде, где метод getConnection вызывался, параметры dbName и userName были перепутаны. И компилятор ничего не мог сделать.

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

E>(кстати, за красоту всегда приходится расплачиваться, чем в данном случае?).
Пока что придется расплачиваться отсутствием индустриальной поддержки, редкостью кадров, иногда — более низкой производительностью. Но все это не связано с выводом типов .

E>Если мне не отшибает память, в Modula-2 и Ada, а так же D, можно было назначать псевдонимы именам типов (вводить подтипы). При этом подтипы дальше существовали как отдельные типы, их нельзя было просто так смешивать с другими типами. Что-то вроде:
В C++ это тоже можно обойти, завернув данные в структуру, просто писанины больше. В ML есть 2 варианта: использовать вариантный тип или инкапсулировать тип в модуль.
E>Все. Просто и надежно.
В большинстве случаев не так просто и надежно. Часто с данными производят какие-то вычисления (из пароля с именем юзера вполне можно посчитать какой-то хэш, ширину умножить на высоту и получить площадь и т.д.) — если типы намеренно делаются несовместимыми, работать с ними становится неудобно, в какой-то момент из обертки все равно нужно получить значения родных типов, и в этот момент их можно опять перепутать. Думаю, потому в большинстве библиотек, которые я видел, точки конструируются из пар чисел, а не из несовместимых типов XCoord, YCoord, а имя юзера и пароль передаются как строки.

И чтобы беседа окончательно не ушла в сторону, настойчиво резюмирую — вывод типов здесь не при чем.

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

E>>Если мне не отшибает память, в Modula-2 и Ada, а так же D, можно было назначать псевдонимы именам типов (вводить подтипы). При этом подтипы дальше существовали как отдельные типы, их нельзя было просто так смешивать с другими типами. Что-то вроде:
PA>В C++ это тоже можно обойти, завернув данные в структуру, просто писанины больше.

Т.е., фактически, не применимо на практике.

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

Так в том-то и дело, что все моменты смешения подтипов требуют явного приведения типов. А это сразу бросается в глаза (по аналогии с рекомендацией использовать static_cast вместо приведения в стиле C в C++). И таких моментов, имхо, набирается не много.

PA> Думаю, потому в большинстве библиотек, которые я видел, точки конструируются из пар чисел, а не из несовместимых типов XCoord, YCoord, а имя юзера и пароль передаются как строки.

А тебе часто приходилось работать с Modula-2 или Ada библиотеками?

PA>И чтобы беседа окончательно не ушла в сторону, настойчиво резюмирую — вывод типов здесь не при чем.

Да я совершенно не против вывода типов. И уверен, что они всегда выводятся как нужно. (Это как всегда в программировании: программа всегда в точности делает то, что ей сказали. Другое дело, что программист не всегда понимает, что именно он говорит )
Я просто высказываю свое впечатление об одной из сторон программирования без явной декларации типов: только глядя на код не всегда понятно, с чем имеешь дело. В случае с OCaml на помощь привлекаются mil-файлы. В случае Ruby -- исходники того, что ты применяешь. Но, если показать человеку, который не совсем в теме, код:

make_ipc_controller_pair(
    ipc,
    io_alerter,
    out pair )
    {
        ipc_owner = make_ipc_sap_owner( ipc );
        controller = make_controller();

        result = make_event_handler_controller(
                ipc_owner,
                io_alerter,
                controller );
        if( result==0 )
            {
                pair = make_ipc_controller_pair( ipc, controller );
            }
        return result;
    }

и попросить понять, что здесь происходит, то это будет не так просто, как кажется.
(кстати, этот код очень сильно напоминает Ruby).

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Дык, я не про то. Вот есть у тебя макрос while. Ну или поядреней — using.
СТ>Ты видишь using, а после прохода компилятором по этому месту там совершенно другой код.
СТ>А IDE, чтобы правильно и по месту показывать ошибки должна как-то с этим разбираться.

Хм. Ошибки вообще показывает компилятор. Если они врутри макроса, то он должен показать на макрос. Тут как раз все просто.

Друное дело с комплитом. Макросы могут добавлять, удалять или менять AST. Хорошо бы чтобы при этом IDE отображала реальную картину в реальном времени. Ну, например, добавил я атрибут [XmlSerialize] который приводит к добавлению в класс двух методов — SaveXml() и LoadXml(). Вот хотелось бы, чтобы IDE позволяло эти методы закомплитить.

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

E>Языками нормальными нужно пользоваться:
E>

E>typedef Dictionary< ZoomedFont::ZoomedFontKey, ZoomedFont > Dict;
E>static Dict _fontMap = new Dict( new ZoomedFontKey::ZoomedFontKeyComparer() );
E>

E>

В "нормальном" до таких тонких моментов просто не доходит.

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

C>Вам бы помогли typedef'ы

Мне бы помог вывод типов. А typedef перед единственным использованием особо ничем помочь не сможет. Хотя в общем, действительно нечто вроде локального и совсем глобального (на проект) using-а было бы удобно иметь.

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

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

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



G>>Ну да. Я — ничего не перепутал. Еще что-нибудь сказать есть, кроме междометий?

Ш>Есть -- вообще-то в С++ при вызове шаблона функции поисходит вывод типа. Лет уже 15 как.

Под выводом типа во всей ветке имеется в виду вывод типа в функции вне конектса вызова. Этого в С++ нет. Лет 15 как. И еще лет 15 не будет. О том, что проверка типов выполняется при инстанциации (то что там происходит, выводом типов назвать язык не поворачивается), я написал. Хватит цепляться к словам.

G>>Это не идея. Это я на яблоках, прибегая к аналогиям, объясняюю, на что похож вывод типов в языках с системой Хиндли-Милнера. С расчетом на то, что до знающего С++ человека дойдет, зачем это надо. А ты все перепутал. В любом случае — если так не понятно, значит уже не вдолбить никак. По крайней мере, у меня идей больше нет, как объяснить.

Ш>Хамить не надо. Не умеешь объяснять доходчиво свои мысли -- лучше не пиши ничего.

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

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

G>Под выводом типа во всей ветке имеется в виду вывод типа в функции вне конектса вызова. Этого в С++ нет. Лет 15 как. И еще лет 15 не будет. О том, что проверка типов выполняется при инстанциации (то что там происходит, выводом типов назвать язык не поворачивается), я написал. Хватит цепляться к словам.
Конечно, вывода типов в духе ML или, пуще того, Haskell, в C++ нет и не будет.
Но справедливости ради следует признать, что при инстанциации шаблонов выполняется не только проверка типов, а нечто большее — подходящая функция или перегруженный оператор при компиляции повыражения выбирается на основании правил перегрузки, на основании ее типа определяется тип подвыражения с вызовом, и процесс повторяется рекурсивно — тип результирующего выражения может получиться довольно сложным, и семантика выражения зависит именно от выведенных таким образом типов — наиболее ярко это проявляется в expression templates. Конечно, сравнивать C++ с ФЯ, где вся программа является выражением, смысла нет.

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

PA>Конечно, вывода типов в духе ML или, пуще того, Haskell, в C++ нет и не будет.
PA>Но справедливости ради следует признать, что при инстанциации шаблонов выполняется не только проверка типов, а нечто большее — подходящая функция или перегруженный оператор при компиляции повыражения выбирается на основании правил перегрузки, на основании ее типа определяется тип подвыражения с вызовом, и процесс повторяется рекурсивно — тип результирующего выражения может получиться довольно сложным, и семантика выражения зависит именно от выведенных таким образом типов — наиболее ярко это проявляется в expression templates. Конечно, сравнивать C++ с ФЯ, где вся программа является выражением, смысла нет.

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

То, что в С++ "тоже есть, с таким же названием, но только совсем не то" — второстепенный и не относящийся к делу момент.

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

Кончай гнать.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы