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

DM>В выступлении Андерс говорит (29:50): I'd say that the first with F# is that it is at least to my knowledge the first functional programming language that sits on top of an industrial strength platform and tools.
DM>Складывается впечатление, что либо Nemerle и Scala он не считает функциональными, либо не знает о них.

На 58-ой минуте (точнее 58:20) появляется слайд на котором присутствуют все перечисленные языки:

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

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


VD>У меня еще пол года назад сложилось устойчивое ощущение, что он и через 20 лет не особо обращает внимание на окружающий мир. Ну, а уж 5-7 лет тому назад точно не обращал. Иначе не было бы столь интуитивных и столь же недальновидных решений вроде делегатов.

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

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

L>языкам или ide?

Языки.

Что же касается коммерческих, то их век прошел. Заработать на языках и IDE тяжело. Приходится бороться с одной стороны с опенс-сорсом где все стоит ровно 0, а с другой с монстрами вроде Майкрософт и Сан. У них вопросов прибыльности направления компляторостроения и IDE нет. Для них это средство удержания рынка.

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

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

Не ты ли тут недавно цитировал про курицу и яичницу?

VD> Я вот тоже раньше имел представление как на автомобиле ездить. А когда начал водить, то понял, что имел только представление.

Поздравляю.

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

VD>>У меня еще пол года назад сложилось устойчивое ощущение, что он и через 20 лет не особо обращает внимание на окружающий мир. Ну, а уж 5-7 лет тому назад точно не обращал. Иначе не было бы столь интуитивных и столь же недальновидных решений вроде делегатов.

V>Вопрос по-прежнему спорный, насчёт архитектуры делегатов. Она мне тоже во многом не нравится (сначала надо было генерики спроектировать, а потом уже делегаты, чтобы получить совместимость по сигнатурам), но не могу не признать её экономичность, т.к. делегаты "унифицируют" колбеки, избавляя компиляторы от необходимости генерировать тонны анонимных функциональных объектов-делегатов. Именно из-за такой "унификации" динамические ФП выглядят чище, т.к. тоже избавлены от той же необходимости генерировать по новому анонимному функциональному типу на каждый чих.

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

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

L>>языкам или ide?

VD>Языки.

VD>Что же касается коммерческих, то их век прошел. Заработать на языках и IDE тяжело. Приходится бороться с одной стороны с опенс-сорсом где все стоит ровно 0, а с другой с монстрами вроде Майкрософт и Сан. У них вопросов прибыльности направления компляторостроения и IDE нет. Для них это средство удержания рынка.

То есть ты согласен со мной, что тезис

Сейчас на язык без удобной IDE и отладчика даже смотреть особо не станут

неверен?

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

L>То есть ты согласен со мной, что тезис
L>

Сейчас на язык без удобной IDE и отладчика даже смотреть особо не станут

L>неверен?

Да.

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

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

Как это можно было сделать в языке, в котором не было generic-ов?
Или ты считаешь, что их вообще не стоило включать, даже в том виде, в котором они есть?

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

L>>То есть ты согласен со мной, что тезис
L>>

Сейчас на язык без удобной IDE и отладчика даже смотреть особо не станут

L>>неверен?

VD>Да.

Вау. Я в шоке.

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

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

L>Как это можно было сделать в языке, в котором не было generic-ов?

Без дженериков конечно прешлось бы генерировать типы.

L>Или ты считаешь, что их вообще не стоило включать, даже в том виде, в котором они есть?

О чем речь?

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

L>Вау. Я в шоке.

От того что с тобой согласились?
Это бывает так редко?

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

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

L>>Как это можно было сделать в языке, в котором не было generic-ов?

VD>Без дженериков конечно прешлось бы генерировать типы.

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

L>>Или ты считаешь, что их вообще не стоило включать, даже в том виде, в котором они есть?

VD>О чем речь?

О делегатах, вестимо.

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

L>>Вау. Я в шоке.

VD>От того что с тобой согласились?
VD>Это бывает так редко?

Со мной это бывает часто. А вот с тобой...

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

VD>>Без дженериков конечно прешлось бы генерировать типы.

L>Т.е. собственно тот вариант, который и был выбран разработчиками языка?

Я о другом говорил. В делегатах проблема не в том, что для них что-то генерирую или нет. Их проблема в том, что они жестко задают этот тип (семантически). Скажем:

delegate int A(int a);

и

delegate int B(int b);

разные типы. И когда я пишу:

var x = y => y * y;

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

Если же мы имеем семантику фунционального типа, то данное выражение будет верно так как оно будет иметь тип int -> int.

То что компилятор где-то за кулисами сгенерирует для описания "int -> int" некий тип класс (или еще что-то) ничего не значит для семантики языка. Ведь везде где компилятор встретит значение типа "int -> int" (или выведет) он подставит этот сгенерированный тип.

L>>>Или ты считаешь, что их вообще не стоило включать, даже в том виде, в котором они есть?

VD>>О чем речь?

L>О делегатах, вестимо.

Я считаю, что вместо делегатов нужно было включать функциональные типы как это было сделано в F#, Nemerle и Scala. Прошу заметить, что все эти языки были созданы еще до поддержки дженериков CLR-ом, но при этом прекрасно работали.

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

VD>>От того что с тобой согласились?
VD>>Это бывает так редко?

L>Со мной это бывает часто. А вот с тобой...

Ты что-то путаешь. Я соглашаюсь с любым разумным мнением. Но не у всех мнения разумны.

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

L>>Т.е. собственно тот вариант, который и был выбран разработчиками языка?

VD>Я о другом говорил. В делегатах проблема не в том, что для них что-то генерирую или нет. Их проблема в том, что они жестко задают этот тип (семантически). Скажем:
VD>

delegate int A(int a);

VD>и
VD>

delegate int B(int b);

VD>разные типы. И когда я пишу:
VD>

VD>var x = y => y * y;
VD>

VD>компилятор не может понять, что за тип я имею в виду.

VD>Если же мы имеем семантику фунционального типа, то данное выражение будет верно так как оно будет иметь тип int -> int.

VD>То что компилятор где-то за кулисами сгенерирует для описания "int -> int" некий тип класс (или еще что-то) ничего не значит для семантики языка. Ведь везде где компилятор встретит значение типа "int -> int" (или выведет) он подставит этот сгенерированный тип.

Если компилятор сгенерил тип, то он должен где-то в какой-то сборке лежать.
Если у нас есть, например, в сборке AsmA у какого-то класса A свойство AProp типа int->int, и в сборке AsmВ у класса B свойство BProp типа int->int, то что произойдет при попытке присвоения a.AProp = b.BProd?

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

VD>Но не у всех мнения разумны.

..., кроме тебя

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

L>Если компилятор сгенерил тип, то он должен где-то в какой-то сборке лежать.

И что это проблема какая-то? Я просто не смотрел реализации которая была до дженериков, так, что не могу сказать как это было реально реализовано. Но это работало.
Кстати, насколько я помню, по крайней мере, в Немерле дженерики были всегда. Только до их поддержке в дотнете они эмулировались компилятором. В Скале это происходит и сейчас, так как Ява поддержки дженериков в рантайме не имеет. Так вот скорее всего эту хитрую генерацию типов и все что связано с их совместимостью обеспечивал сам компилятор при эмуляции дженериков. А уже фунциональные типы были написаны поверх дженериков.
Вот цитата с сайта: http://nemerle.org/Release_schedule

0.9.x (formerly known as 0.4)
* Implement .NET runtime generics feature (Nemerle used erasure technique before for compiling generic types, just like Java 5.0)
* Improve matching compiler to produce cleaner and more optimized code

L>Если у нас есть, например, в сборке AsmA у какого-то класса A свойство AProp типа int->int, и в сборке AsmВ у класса B свойство BProp типа int->int, то что произойдет при попытке присвоения a.AProp = b.BProd?

Присвоится.

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

L>>Если компилятор сгенерил тип, то он должен где-то в какой-то сборке лежать.

VD>И что это проблема какая-то? Я просто не смотрел реализации которая была до дженериков, так, что не могу сказать как это было реально реализовано. Но это работало.

Ну вообще-то, да проблема. Если типы разные, то они совместимы не будут. Как с ними работать-то тогда?

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

Тогда я не понимаю, как это может работать вне одной сборки?

L>>Если у нас есть, например, в сборке AsmA у какого-то класса A свойство AProp типа int->int, и в сборке AsmВ у класса B свойство BProp типа int->int, то что произойдет при попытке присвоения a.AProp = b.BProd?

VD>Присвоится.

А если через Reflection?
А a.AProp.GetType() == b.BProd.GetType() что вернет?

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

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

L>>По руби уже есть пара книжек и на русском.

VD>Может быть. Но уверен, что если зайти в "книжный" (реальный, а не виртуальный), то их ты не увидишь. А вот книги по С++ будут в самом центре. Создаётся впечатление, что все учат только его, а те же Явы и дотента как бы и нет вовсе (про Руби просто молчу).

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