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

VD>>Например, Симон разработал Дженерики. На мой взгляд вклад был намного более значительным. Но почему-то он не столь легендарен.
EC>Симон это Саймон Пейтон Джонс? Если да, то ты что-то путаешь.

Нет, это Don Syme — разработчик F#

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

DM>>Это дополнительная степень типобезопасности, если угодно.
IT>А где в данном случае опасность?

Опасность совершить логическую ошибку — использовать не ту функцию. Это следующий уровень антиграблевости, подобно фантомным типам в ФЯ.

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

DM>Опасность совершить логическую ошибку — использовать не ту функцию. Это следующий уровень антиграблевости, подобно фантомным типам в ФЯ.

Что значти не ту функцию? Функция не имеет тип делегата. У неё есть сигнатура, которая может быть использована с разными делегатами.

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

S>Нет, это Don Syme — разработчик F#

Я в курсе, ещё Andrew Kennedy к ним руку приложил.

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

DM>>Опасность совершить логическую ошибку — использовать не ту функцию. Это следующий уровень антиграблевости, подобно фантомным типам в ФЯ.

IT>Что значти не ту функцию? Функция не имеет тип делегата. У неё есть сигнатура, которая может быть использована с разными делегатами.

Это по аналогии со strong typedef в некоторых языках (Ada и D) -- от какого-то типа можно произвести подтип, несовместимый с исходным. Что-то вроде:

typedef string Password;
typedef string Username;

DBConnection getDbConnection( Username user, Password password ) { ... }
...
string user = getCurrentUser(...);
string password = getUserPassword( user );
DBConnection db = getDbConnection( password, user ); // Компилятор даст по рукам!

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

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

KV>В PHP 5.3 (он пока еще в альфе) появились лямбды и замыкания.

Мне кажется PHP на этой картинке явно лишний.

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

L>А если его не нашли?

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

L>Но там не менее, решение из Nemerle — заведомо правильное, а из C# — нет?

Аналогичные решения были в F# и в Scala. Скала, до сих пор использует эмуляцию дженериков, так как Ява не поддерживает их в рантайме.
Тебе этого мало?
Собственно решение взято даже не из этих языков, а из теории лежащей самого ФП который базируется на лямбда исчислении Черча.
В общем, это та база (те знания) которые было необходимо иметь прежде чем развивать Яву.
Детали реализации и есть детали которые должен был продумывать архитектор конкретного языка. Для F#, Scala и Nemerle (языков выполняемых на базе .Net или Явы) это было сделано. Для Шарпа — нет. В конце концов работу по дженерикам Симон закончил еще в 2002-ом, так что можно было просто подождать с выходом дотнета на рынок, но добавить поддержку дженериков (если уж с ними все настолько проще и логичнее получается).

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

L>Комментарий не в тему. Я спрашивал о том, как могли существовать "нормальные" делегаты для .Net 1.* (в отсутствие дженериков).

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

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

DM>А вот тут отдельный философский вопрос — хорошо это или плохо.

Тут какое дело. Форум (куда снесли тему) конечно соответствующий и по филосовствовать в нем каждый не прочь. Но вопрос данный отнюдь не философский, а что не на есть теоретико-практический. С точки зрения теории, есть теория лябда-исчислений Черча которая описывает очень много чего и которая позволяет сделать решение заведомо полноценным и непротиворечивым. С точки зрения практики есть целая толпа функциональных, статически типизированных языков языков использующих данный подход (основанный на теории). Они существуют уже много лет (более 25 точно) и вопросы связанные с манипуляцией функциями в них вылизан до блеска.
Так вот на эту тему создано множество научных работ (мэйнстриму такого и не снилось), проведено множество экспериментов, ну конечно же сделаны выводы.
Люди которые основательно познакомились с теорией и/или практикой ФП уверены в неверности выбора дизайнеров Шарпа. Минусы наставленные тебе как раз это подтверждает.
Посему просто не надо философствовать на эту тему. Просто разберись с теорией и практикой.

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

DM>Если у нас описаны делегаты
DM>

DM>delegate int Square(int n); //returns n squared
DM>и
DM>delegate int LaunchMissiles(int n); //returns number of launched missiles
DM>

DM>и некая функция принимает на вход делегат первого вида, то очень даже хорошо, что компилятор не даст передать туда делегат второго вида. Это дополнительная степень типобезопасности, если угодно.

Смотри как легко ломается твоя "теория".
Предположим мы имеем две функцию высшего порядка (ФВП, смотри определение в Википедии):

int MyAlghorinmWhichNeedSquareFunc(Square square)
{
  int n = ...;
  ...
  return square(n);
}

Теперь мы имеем два метода:

int CalcSquare(int n) { n * n }
int LaunchMissiles(int countMissilesToLaunc) { реализация ... }

Казалось бы мы защищены от пуска ракет?! Ан не тут то было. Код:

int result = MyAlghorinmWhichNeedSquareFunc(Square(LaunchMissiles));

или даже:

int result = MyAlghorinmWhichNeedSquareFunc(LaunchMissiles);

Проходит на ура! И мы убиваем пол Европы простой ошибкой в передаче функции.


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

strong type def B  = A;

Тогда компилятор для кода:

A a = new A();
B b = a;  // E: тип А не совместим с типом B.

выдаст ошибку во второй строке.
Тогда имея функциональный тип int -> int мы бы смогли (если бы это потребовалось) создать два строгих типа:

strong type def Square         = int -> int;
strong type def LaunchMissiles = int -> int;

эти типы не были бы совместимы между собой.
Для функций такая фича явно не нужна, но для других типов это могло бы быть очень удобно. Например, если мы имеем разные системы координат, то можно было бы один раз объявить тип координата (как структура, например) и создать другой тип через "strong type def". Это избавило бы нас от подстановки координат созданных в одной системы в другую без преобразования.

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

DM>>Опасность совершить логическую ошибку — использовать не ту функцию. Это следующий уровень антиграблевости, подобно фантомным типам в ФЯ.

IT>Что значти не ту функцию? Функция не имеет тип делегата. У неё есть сигнатура, которая может быть использована с разными делегатами.

2D. Mon: Другими словами ошибку этим ты не предотвратишь. Это я продемонстрировал в сообщении рядом.

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

L>Еще раз:
L>

L>Приведи пример, где я "вырвал слова из предложения"

Ты вырвал их из контекста. А как — это уже детали.

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

VD>Мне кажется PHP на этой картинке явно лишний.

А жабо-скрипт прям как родной, да?

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

VD>Для функций такая фича явно не нужна, но для других типов это могло бы быть очень удобно. Например, если мы имеем разные системы координат, то можно было бы один раз объявить тип координата (как структура, например) и создать другой тип через "strong type def". Это избавило бы нас от подстановки координат созданных в одной системы в другую без преобразования.

Разные типы эту проблему разве не решают?

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

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

L>>Комментарий не в тему. Я спрашивал о том, как могли существовать "нормальные" делегаты для .Net 1.* (в отсутствие дженериков).

VD>Надоел. Тебе ответили. Иди и изучай. Скала до сих пор дженерики эмулирует. Качай код и смотри реализацию.

Мне тут один человек рассказал, что реализация делегатов в шарпе — неправильная, а в ф-шарпе/скале/немерле — правильная. Если он столь уверенно выражает свое мнение, а других называет неучами и неумехами, то мне видится только два варианта:
1) наверное он глубоко изучил этот вопрос и знает, где была совершена ошибка.
2) "... знать она сильна, что лает на слона" (с)

Как-то так.

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

L>>Еще раз:
L>>

L>>Приведи пример, где я "вырвал слова из предложения"

VD>Ты вырвал их из контекста. А как — это уже детали.

Можно ли из неверных по отдельности утверждений составить верно?

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

ВВ>А жабо-скрипт прям как родной, да?

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

Видимо тут играют роль знания того кто рисовал картинку или известность для аудитории.

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

AVK>Вопрос только в том, что считать потыкиванием, а что распробованием. Предложение IT потратить на это несколько месяцев идет в лес за несовместимостью со здравым смыслом.

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

AVK>И еще — на основании чего ты оцениваешь уровень моего знакомства?

А я и не оцениваю. Я просто отвечал на твои слова о том, что "жалко тратить время". На мой взгляд — зря. Но решаешь конечно ты.

AVK>Или все, кто потратил достаточно, должны считать Немерле лучшим языком, я правильно понимаю?

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

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

AVK>Тем не менее это не помешало тебе выбрать автомобиль, имея нулевой опыт вождения.

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

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

L>Мне тут один человек рассказал, что реализация делегатов в шарпе — неправильная, а в ф-шарпе/скале/немерле — правильная. Если он столь уверенно выражает свое мнение, а других называет неучами и неумехами, то мне видится только два варианта:
L>1) наверное он глубоко изучил этот вопрос и знает, где была совершена ошибка.
L>2) "... знать она сильна, что лает на слона" (с)

L>Как-то так.

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

Всю свою софистику оставь при себе.

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

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

ВВ>>А жабо-скрипт прям как родной, да?
VD>Ну, в нем есть интересные концепции.

Ну на таком уровне и в php в общем-то тоже.

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

E>Это по аналогии со strong typedef

http://rsdn.ru/forum/message/3149641.1.aspx

Автор: VladD2
Дата: 23.10.08

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

L>>Мне тут один человек рассказал, что реализация делегатов в шарпе — неправильная, а в ф-шарпе/скале/немерле — правильная. Если он столь уверенно выражает свое мнение, а других называет неучами и неумехами, то мне видится только два варианта:
L>>1) наверное он глубоко изучил этот вопрос и знает, где была совершена ошибка.
L>>2) "... знать она сильна, что лает на слона" (с)

L>>Как-то так.

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

То есть ты их не знаешь, я правильно понял?

VD>Всю свою софистику оставь при себе.

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

Чем дальше, тем больше склоняюсь к пунку 2)