Luke Hoban — program manager C# IDE. Позавчера мне удалось немножко его потерзать на тему C# 3.0. Постараюсь вкратце изложить (но могу чего нибудь забыть, очень спать хочется).
1) 5 дней назад окончательно были выкачены спецификации на join в LINQ-запросе
2) По поводу недоступности анонимных типов вне контекста функции: проблема известна, но по поводу ее решения он ничего сказать не смог. Боюсь, в релизе linq все останется как есть сейчас.
3) По поводу миксинов: вещь однозначно полезная, но они пока не знают как это реализовать в C#. К релизу LINQ ничего сделать они точно не успеют. В дальнейшем вполне возможно.
4) По поводу возможности расширения компилятора (AST-макросы, etc): технических проблем нет, но они этого не делают, потому что это приведет к созданию кучи различных языков разными командами, и этот код будет несовместим, а порог вхождения в команду будет слишком высоким.
5) По поводу компилятора Expression Tree: он не сразу понял что я хочу. Когда понял, сказал что над этим вроде как никто не думал, так что стоит написать ему для чего это нужно. ИМХО лучше все же написать сразу на фидбек, но надо грамотно все оформить.
6) По поводу сроков: очередной CTP выйдет в конце апреля- начале мая. Основные изменения — сильно переделан DLINQ. Про join я уже писал.
7) По поводу конфликтов extension-методов: в случае, если в using будут указаны два расширения с одинаковыми методами для одинаковых типов компилятор сгенерит ошибку ambiguous extension methods.
8) По поводу многострочных лямбд: ошибка компилятора. Будет исправлена.
P.S. Много разговаривали с Клеменсом Вастерсом (он нынче program manager WCF). Описывать долго, так что если у кого есть какие вопросы — могу попробовать ответить.
Здравствуйте, AndrewVK, Вы писали:
AVK>Luke Hoban — program manager C# IDE. Позавчера мне удалось немножко его потерзать на тему C# 3.0. Постараюсь вкратце изложить (но могу чего нибудь забыть, очень спать хочется).
AVK>4) По поводу возможности расширения компилятора (AST-макросы, etc): технических проблем нет, но они этого не делают, потому что это приведет к созданию кучи различных языков разными командами, и этот код будет несовместим, а порог вхождения в команду будет слишком высоким.
Ну-ну. AVK>5) По поводу компилятора Expression Tree: он не сразу понял что я хочу. Когда понял, сказал что над этим вроде как никто не думал, так что стоит написать ему для чего это нужно. ИМХО лучше все же написать сразу на фидбек, но надо грамотно все оформить.
Я сразу понял чего ты хочешь. Но у меня еще вопрос который я так и не понял. Допустим у меня в файле лежит запрос. Могу ли я его прочитать и выполнить? (никакой инфы не нашел). AVK>6) По поводу сроков: очередной CTP выйдет в конце апреля- начале мая. Основные изменения — сильно переделан DLINQ.
Успели таки. Только я хотел гневно высказаться по DLinq'у на КЫВТ, а тут они телепатно сообразили. Боятся значит уважают.
Здравствуйте, GlebZ, Вы писали:
GZ>Я сразу понял чего ты хочешь. Но у меня еще вопрос который я так и не понял. Допустим у меня в файле лежит запрос. Могу ли я его прочитать и выполнить? (никакой инфы не нашел).
Запрос на LINQ? Или Expression Tree? Если первое, то только если csc.exe запускать. Я же тебе уже писал — ты неверно воспринимаешь LINQ — это языковая конструкция. Твой вопрос аналогичен вопросу — можно ли выполнить сохраненный в файле foreach. Ответ на него, я думаю, ты знаешь.
AVK>Запрос на LINQ? Или Expression Tree? Если первое, то только если csc.exe запускать. Я же тебе уже писал — ты неверно воспринимаешь LINQ — это языковая конструкция. Твой вопрос аналогичен вопросу — можно ли выполнить сохраненный в файле foreach. Ответ на него, я думаю, ты знаешь.
я правильно понял, что Expression Tree это как раз средство позволяющее
в том числе сохранять и загружать запросы? аналог ICriteria в (N)Hibernate?
Здравствуйте, AndrewVK, Вы писали:
AVK>Запрос на LINQ? Или Expression Tree? Если первое, то только если csc.exe запускать. Я же тебе уже писал — ты неверно воспринимаешь LINQ — это языковая конструкция. Твой вопрос аналогичен вопросу — можно ли выполнить сохраненный в файле foreach. Ответ на него, я думаю, ты знаешь.
Запрос на LINQ. Это в принципе даже не чистая языковая конструкция, это препроцессор.
Но допустим мы имеем строку с LINQ, далее мы из нее делаем Expression Tree, как далее ты наверно лучше меня понимаешь. Я думаю, это значительно расширит применимость LINQ( и применимость компилятора).
Здравствуйте, Ziaw, Вы писали:
Z>аналог ICriteria в (N)Hibernate?
ICriteria не сериализуется, так что уже точно не аналог
Имхо ICriteria нужен исключительно для того, чтобы построить что-то вроде дерева запроса HQL вместо использования конкатенации строк для построения запроса.
O>ICriteria не сериализуется, так что уже точно не аналог
ну сериализация не единственный способ сохранения
O>Имхо ICriteria нужен исключительно для того, чтобы построить что-то вроде дерева запроса HQL вместо использования конкатенации строк для построения запроса.
ну да, это и есть Expression Tree. не то что бы незаменимая вещь, но часто
дающая большую гибкость и прозрачность построения и передаче запросов.
необходимость ее использования возникала у меня всего пару раз, но переписывать
тот код без ее использования я бы побоялся.
Здравствуйте, AndrewVK, Вы писали:
AVK>4) По поводу возможности расширения компилятора (AST-макросы, etc): технических проблем нет, но они этого не делают, потому что это приведет к созданию кучи различных языков разными командами, и этот код будет несовместим, а порог вхождения в команду будет слишком высоким.
Фиговая отмазка. Беспокоятся они о нас болезных
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
AVK>>4) По поводу возможности расширения компилятора (AST-макросы, etc): технических проблем нет, но они этого не делают, потому что это приведет к созданию кучи различных языков разными командами, и этот код будет несовместим, а порог вхождения в команду будет слишком высоким.
IT>Фиговая отмазка. Беспокоятся они о нас болезных
После введения таких фич накроются медным тазом рефакторинг фичи их и не только их ИДЕ. имхо.
Здравствуйте, Ziaw, Вы писали:
O>>ICriteria не сериализуется, так что уже точно не аналог Z>ну сериализация не единственный способ сохранения
А как ещё ты будешь сохранять ICriteria?
CriteriaImpl несёт с собой дофига информации, не относящейся напрямую к запросу, так что сделать ручную сериализацию CriteriaImpl будет тяжело. Прийдётся фактически писать для этого какие-то свои классы и использовать их вместо ICriteria... Т.е. сам ICriteria по себе не является аналогом expression trees в DLinq
Z>ну да, это и есть Expression Tree. не то что бы незаменимая вещь, но часто Z>дающая большую гибкость и прозрачность построения и передаче запросов. Z>необходимость ее использования возникала у меня всего пару раз, но переписывать Z>тот код без ее использования я бы побоялся.
Одна из основных фишек этих expression trees в DLinq, насколько я понял, именно в том, что их можно передавать туда-сюда. Так что тут всё зависит от того, как мы используем терминологию.
O>CriteriaImpl несёт с собой дофига информации, не относящейся напрямую к запросу, так что сделать ручную сериализацию CriteriaImpl будет тяжело. Прийдётся фактически писать для этого какие-то свои классы и использовать их вместо ICriteria... Т.е. сам ICriteria по себе не является аналогом expression trees в DLinq
придется писать свои классы для сохранения, зачем их использовать вместо?.
Z>>ну да, это и есть Expression Tree. не то что бы незаменимая вещь, но часто Z>>дающая большую гибкость и прозрачность построения и передаче запросов. Z>>необходимость ее использования возникала у меня всего пару раз, но переписывать Z>>тот код без ее использования я бы побоялся.
O>Одна из основных фишек этих expression trees в DLinq, насколько я понял, именно в том, что их можно передавать туда-сюда. Так что тут всё зависит от того, как мы используем терминологию.
Здравствуйте, Ziaw, Вы писали:
Z>придется писать свои классы для сохранения, зачем их использовать вместо?.
Да потому, что ICriteria несёт с собой слишком много служебной информации и легче будет написать что-то вроде обёртки, т.е. в итоге реализовать как минимум тот же набор методов у себя. Это будет действительно непросто — поверь мне на слово. Если не веришь — реализацию классов сохранения/поднятия в студию
Это так потому, что ICriteria в Hibernate изначально проектировалась не для тех же целей, для каких проектировались expression trees. Например, дизайнеры Hibernate и не думали, что кому-то прийдёт в голову сериализовать ICriteria. Обрати внимание, что ICriteria даже не может быть приаттачен к другой сессии штатными средствами!
Z>ну мы сошлись во мнениях как я понял.
Ну если ты согласен, что ICriteria != DLinq Expression Tree по набору фич, то сошлись.
O>Ну если ты согласен, что ICriteria != DLinq Expression Tree по набору фич, то сошлись.
я где то писал что у них одинаковый набор фич? я только спросил не аналогичные ли это инструменты. в моем понимании они оказались аналогичными.
Здравствуйте, Ziaw, Вы писали:
O>>Ну если ты согласен, что ICriteria != DLinq Expression Tree по набору фич, то сошлись. Z>я где то писал что у них одинаковый набор фич? я только спросил не аналогичные ли это инструменты. в моем понимании они оказались аналогичными.
Судя по всему не все понимают что такое Expression Tree, поэтому простенький пример:
using System;
using System.Query;
using System.Expressions;
class Test
{
static void Main()
{
// Lambda = anonymous method
Func<int, string> f = p => "p = " + (p + 1);
Console.WriteLine(f(12));
// The same lambda, but in expression tree form
Expression<Func<int, string>> ft = p => "p = " + (p + 1);
Console.WriteLine(ft);
// Iterate over lambda parameters and print itforeach (ParameterExpression pe in ft.Parameters)
Console.WriteLine("{0} : {1}", pe.Name, pe.Type);
}
}
Результат:
p = 13
|p| Concat("p = ",Add(p, 1)
p : System.Int32
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, prVovik, Вы писали:
V>>После введения таких фич накроются медным тазом рефакторинг фичи их и не только их ИДЕ. имхо.
IT>Значит надо поситеть и подумать головой, чтобы не накрылись.
Ну вот, видимо, посидели и подумали
Просто сама идея автоматизированного рефакторинга не дружит с макросами и фокусами с АСТ, так как тут рафакторинг тулза помимо того, что должна уметь исполнять хитроумные и навороченные макросы (простые нам не нужны ), что само по себе не просто, но и заниматься реинжинирингом, что в общем случае сделать невозможно. То есть тут на карте либо автоматизированный рефакторинг, либо навороченные макросы. Выбрали, похоже, первое (имхо, правильно сделали). Все, конечно, ИМХО.
Здравствуйте, prVovik, Вы писали:
V>Ну вот, видимо, посидели и подумали
Добавлю. Как ты думаешь, почему у С++ компиляторов такие убогие сообщения об ошибках, когда дело касается шаблонов, даже несмотря на то, что шаблоны обладают весьма скудными возможностями по части метапрограммирования по сравнению со многими макросами? Да все потой же причине, по которой макросы не дружат с автоматизированным рефакторингом А именно с необходимостью реинжиниринга, чтобы можно было понять, "откуда ноги растут".
Здравствуйте, prVovik, Вы писали:
V>Просто сама идея автоматизированного рефакторинга не дружит с макросами и фокусами с АСТ, так как тут рафакторинг тулза помимо того, что должна уметь исполнять хитроумные и навороченные макросы (простые нам не нужны ), что само по себе не просто, но и заниматься реинжинирингом, что в общем случае сделать невозможно.
Почему реинжинирингом? Разве рефактореры занимаются реинжинирингом? Мне почему-то всегда казалось, что компиляцией на лету
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Почему реинжинирингом? Разве рефактореры занимаются реинжинирингом? Мне почему-то всегда казалось, что компиляцией на лету
Это если код статичный. А если он начинает меняться в процессе компиляции, то потребуется искать, откуда в исходном коде растут ноги. Хотя, возможно, что я что-то путаю...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, prVovik, Вы писали:
V>>Просто сама идея автоматизированного рефакторинга не дружит с макросами и фокусами с АСТ, так как тут рафакторинг тулза помимо того, что должна уметь исполнять хитроумные и навороченные макросы (простые нам не нужны ), что само по себе не просто, но и заниматься реинжинирингом, что в общем случае сделать невозможно.
IT>Почему реинжинирингом? Разве рефактореры занимаются реинжинирингом? Мне почему-то всегда казалось, что компиляцией на лету
Да и плюс к тому, упомянутая выше проблема с человеческими сообщениями об ошибках.
Здравствуйте, prVovik, Вы писали:
V>Да и плюс к тому, упомянутая выше проблема с человеческими сообщениями об ошибках.
В Немерле эта проблема решается. И вообще, если проблемы есть, то их надо решать, а не отмазываться беспокойством о трудности вхождения в команду. В конце концов DSL пока ещё никто не признал абсолютным злом, а некоторые считают их будущим человечества.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, prVovik, Вы писали:
V>>Да и плюс к тому, упомянутая выше проблема с человеческими сообщениями об ошибках.
IT>В Немерле эта проблема решается.
Здравствуйте, prVovik, Вы писали:
IT>>В Немерле эта проблема решается.
V>можно еще и про отладку шаблонов вспомнить
Проблем с отладкой дженериков тем не менее нет. Всё это решается.
Тебе же сказали, что технических проблем нет. А вот мы с тобой, Вовик, ещё не доросли до AST. Так что собирай свои буквари и тетрадки, enlarge your pencil, иди в школу и буть хорошим мальчиком.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Проблем с отладкой дженериков тем не менее нет. Всё это решается.
А потому что, в дженериках нет никакой динамики, они статичны по сути. Для обработки дженериков не нужно выполнять никаких определенных пользователем алгоритмов. От обработчика дженериков требуется единственное — заранее знать о них, для чего они нужны, что делают и как работают. Я убежден, что автоматизированный рефакторинг возможен только для статичных языков: со статической типизацией, со статичным кодом и пр. Попытка реализовать автоматический рефакторинг для языка с развитой системой макросов — это почти тоже самое, что реализация системы рефакторинга для динамических скриптовых языков.
IT>Тебе же сказали, что технических проблем нет. А вот мы с тобой, Вовик, ещё не доросли до AST. Так что собирай свои буквари и тетрадки, enlarge your pencil, иди в школу и буть хорошим мальчиком.
Ну, отмазка, действительно, нелепая. В крайнем случае VB еще не отменили
V>Я убежден, что автоматизированный рефакторинг возможен только для статичных языков
Кстати, я думаю, что МС будет развивать шарп, добавляя в язык конкретные варианты использования макросов, как это было, например, с дженериками.
Здравствуйте, prVovik, Вы писали:
V>Я убежден, что автоматизированный рефакторинг возможен только для статичных языков: со статической типизацией, со статичным кодом и пр. Попытка реализовать автоматический рефакторинг для языка с развитой системой макросов — это почти тоже самое, что реализация системы рефакторинга для динамических скриптовых языков.
Значит надо думать как подружить рефакторинг и макросы. В конце концов уже давно всем понятно, что язык без качественной IDE сегодня не представляет практически никакой коммерческой ценности. Проблема разработки API способного интегрировать языки в IDE уже давно назрела.
IT>>Тебе же сказали, что технических проблем нет. А вот мы с тобой, Вовик, ещё не доросли до AST. Так что собирай свои буквари и тетрадки, enlarge your pencil, иди в школу и буть хорошим мальчиком. V>Ну, отмазка, действительно, нелепая. В крайнем случае VB еще не отменили
Она ещё более нелепа в свете того, что многие из нас начали свой путь с процедурного программирования. Т.е. ООП мы как-то смогли понять, что такое шаблоны как-то сообразили, на Windows перешли, COM, после 6 месяцев тумана в голове, тоже взяли, а вот DSL и метапрограммирование для нас это слишком сложно. Беспокоются они о нас Детский сад какой-то
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) 5 дней назад окончательно были выкачены спецификации на join в LINQ-запросе
Ничего не понятно.
AVK>2) По поводу недоступности анонимных типов вне контекста функции: проблема известна, но по поводу ее решения он ничего сказать не смог. Боюсь, в релизе linq все останется как есть сейчас.
Уроды.
AVK>3) По поводу миксинов: вещь однозначно полезная, но они пока не знают как это реализовать в C#. К релизу LINQ ничего сделать они точно не успеют. В дальнейшем вполне возможно.
Что там думаь то? Блин, дети из Польши давно все за них продумали. http://nemerle.org/Traits
AVK>4) По поводу возможности расширения компилятора (AST-макросы, etc): технических проблем нет,
Хм. Лучше бы он был осторожнее в высказываниях.
AVK> но они этого не делают, потому что это приведет к созданию кучи различных языков разными командами, и этот код будет несовместим, а порог вхождения в команду будет слишком высоким.
Песнь старая. Видимо по этому многие используют Эмит...
AVK>5) По поводу компилятора Expression Tree: он не сразу понял что я хочу. Когда понял, сказал что над этим вроде как никто не думал, так что стоит написать ему для чего это нужно. ИМХО лучше все же написать сразу на фидбек, но надо грамотно все оформить.
Странно. На п. 4 ответил бодро, а тут не понял. Думаю, он мог так же не верно понять идею макросов.
ЗЫ
Не спрашивал его отношение Немерлу? Они его вообще смотрели?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>я правильно понял, что Expression Tree это как раз средство позволяющее Z>в том числе сохранять и загружать запросы? аналог ICriteria в (N)Hibernate?
Это скорее блеклый аналог квази-цитирования. Только не квази и только для лямбд (а-ка анонимные методы).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Просто сама идея автоматизированного рефакторинга не дружит с макросами и фокусами с АСТ,
Метаатрибуты возможно, и то не все. А макросы-выражения точно в большинстве случаев будут прекрасно рефакториться. Они ведь просто изменяют имеющийся АСТ. А рефакторить нужно исходный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Она ещё более нелепа в свете того, что многие из нас начали свой путь с процедурного программирования. Т.е. ООП мы как-то смогли понять, что такое шаблоны как-то сообразили, на Windows перешли, COM, после 6 месяцев тумана в голове, тоже взяли, а вот DSL и метапрограммирование для нас это слишком сложно. Беспокоются они о нас Детский сад какой-то
Мне кажется на рынке назрела пора создать ЯП который займет явно пустующую нишу удобного и мощьного языка для тех кто не боится С++, но не хочет трахаться с С++ и хочет получить мощьные компонетные возможности дотнета.
Ну, будет линейка VB, C#, N, C++. Кому от этого хуже будет? Ведь явно МС боится спугнуть многих индокодеров с трудом освоивших VB или C# и не способных думать, а спосбных только тупо долбить тупой код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
IT>> Фактически, нас с вами назвали дебилами. Поздравляю!
AVK>Ты преувеличиваешь.
Не он не преувеличивает. Просто нас смешали с тоннами индусов и им подобных жителей америки и вывели, что в среднем мы быдблокодеры. Так что давать нам выходить за рамки вредно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Они ведь просто изменяют имеющийся АСТ. А рефакторить нужно исходный.
Ага, то есть ты предлагаешь рефакторить ДО развертывания макросов без их анализа?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
V>>А потому что, в дженериках нет никакой динамики, они статичны по сути.
VD>Расскажи это ПК. Он тут часто дженерики за излишний динамизм ругал.
Я имеюл ввиду, что они статичны с точки зрения процесса компиляции. Для их компиляции компилятору не следует выполнять никаких определенных пользователем алгоритмов. Фактически, дженерики — это один из вариантов использования макросов, который введен в язык.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
IT>>>В Немерле эта проблема решается.
V>>можно еще и про отладку шаблонов вспомнить
VD>А можно забыть про С++ как про страшный сон. Тогда глядишь и фобии перетанут мучать.
Влад, у тебя параноя. Я уже два года как не написал ни строчки кода на С++ (ну почти ни одной).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
IT>>>В Немерле эта проблема решается.
V>>можно еще и про отладку шаблонов вспомнить
VD>А можно забыть про С++ как про страшный сон. Тогда глядишь и фобии перетанут мучать.
Неужели, в немерле есть отладчик времени компиляции?
Здравствуйте, VladD2, Вы писали:
AVK>>1) 5 дней назад окончательно были выкачены спецификации на join в LINQ-запросе
VD>Ничего не понятно.
Чего не понятно? В следующей версии в декларативном запросе будет JOIN.
AVK>>5) По поводу компилятора Expression Tree: он не сразу понял что я хочу. Когда понял, сказал что над этим вроде как никто не думал, так что стоит написать ему для чего это нужно. ИМХО лучше все же написать сразу на фидбек, но надо грамотно все оформить.
VD>Странно. На п. 4 ответил бодро, а тут не понял. Думаю, он мог так же не верно понять идею макросов.
Нет. Я ему детально объяснил о чем речь. И, судя по реакции, им явно этот вопрос не первый раз задают. Вобще, как ни странно, мужик был грамотный и прекрасно ориентировался в современных языках. К примеру, не надо было объяснять что такое tuple и чем отличается от анонимных типов.
Пугает другое — кроме меня никто не задавал вопросов по дизайну языка. И это сливки программерского сообщества EE&MEA!
VD>Не спрашивал его отношение Немерлу? Они его вообще смотрели?
Не, не спрашивал. А смысл? По поводу AST-макросов он ответил весьма подробно.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, prVovik, Вы писали:
IT>>>>В Немерле эта проблема решается.
V>>>можно еще и про отладку шаблонов вспомнить
VD>>А можно забыть про С++ как про страшный сон. Тогда глядишь и фобии перетанут мучать. V>Неужели, в немерле есть отладчик времени компиляции?
а, ну да, что-то такое есть...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
IT>>> Фактически, нас с вами назвали дебилами. Поздравляю!
AVK>>Ты преувеличиваешь.
VD>Не он не преувеличивает. Просто нас смешали с тоннами индусов и им подобных жителей америки и вывели, что в среднем мы быдблокодеры. Так что давать нам выходить за рамки вредно.
гы, не удивлюсь, если такие макросы в CLI появятся
Здравствуйте, prVovik, Вы писали:
V>Я имеюл ввиду, что они статичны с точки зрения процесса компиляции. Для их компиляции компилятору не следует выполнять никаких определенных пользователем алгоритмов. Фактически, дженерики — это один из вариантов использования макросов, который введен в язык.
Нет, нет, и нет. Дженерики компонентны по сути. Их воплощение происходит в лучшем случае во время инсталляции приложения, а то и при запуске/подгрузке модулей. Посему макросами времени компиляции их полностью не заменить. Хотя конечно во многом они заменимы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Неужели, в немерле есть отладчик времени компиляции?
Ага! И еще какая!!! Код макросов — это код на Немерле. И этим все сказано! Так что все приемы программирования и отладки идентичны как в метакоде, так и в обычном коде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Ага, то есть ты предлагаешь рефакторить ДО развертывания макросов без их анализа?
Да. Это уже даст очнь много.
А для порождающий макросов можно попытаться придумать некую интеграцию с рефакториром. В общем, у меня большая надежда на то, что таки рефакторинг для языков типа Немерла таки будет возможен. Главное, чтобы были люди которые способны сделать это.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Чего не понятно? В следующей версии в декларативном запросе будет JOIN.
Вот так бы и сказал.
AVK>Нет. Я ему детально объяснил о чем речь. И, судя по реакции, им явно этот вопрос не первый раз задают.
Вот и странно, что не понял зачем компилировать деревья выражений.
AVK> Вобще, как ни странно, мужик был грамотный и прекрасно ориентировался в современных языках.
Действительно странно. На работе работают люди которые в ней что-то понимают.
AVK> К примеру, не надо было объяснять что такое tuple и чем отличается от анонимных типов.
Так ты спросил почему они не содрали идею типлов (возможно адаптированную), а стали изобретать кривой велосипед?
AVK>Пугает другое — кроме меня никто не задавал вопросов по дизайну языка. И это сливки программерского сообщества EE&MEA!
Ну, среди этих сливо слишком много случайных крикунов. А многим интересны прикладные вопросы и на средства разработки им начхать.
VD>>Не спрашивал его отношение Немерлу? Они его вообще смотрели?
AVK>Не, не спрашивал. А смысл? По поводу AST-макросов он ответил весьма подробно.
Смысл глубочаший. Макросы только част прелеси этого языка. Язык очень сбалансированный и построен на точной мат.модели. Разработчики Шарпа могли бы много из него почерпнуть. А там и макросами прониклись бы.
Тут такое дело. Немерле нельзя серьезно оценить если не попробовать его самому. Я до сих пор в восторге именно от сбалансированности фичь.
Думаю, что простое изучение языка и компилятора могло бы дать ответы шарповцвам на многие вопросы котоыре сейчас кажутся им неразрешимыми.
Например, я просто таки отчетливо понял что мне нехватало в Р-Шарпе. А до этого пол года ломал голову. И это при том, что про Лисп, Схему, Окамл, Питон, Руби и т.п. я знал не хуже авторов языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Нет, нет, и нет. Дженерики компонентны по сути. Их воплощение происходит в лучшем случае во время инсталляции приложения, а то и при запуске/подгрузке модулей. Посему макросами времени компиляции их полностью не заменить. Хотя конечно во многом они заменимы.
Я об одном, ты про свое. Я говорю о статичности дженериков с точки зрения (веделяю слово не просто так!) процесса компиляции. То есть дженерики ничего не имеют общего с динамическими метапрограммами (макросами). Потому там рефакторинг и работает.
Здравствуйте, VladD2, Вы писали:
VD>Ведь явно МС боится спугнуть многих индокодеров с трудом освоивших VB или C# и не способных думать, а спосбных только тупо долбить тупой код.
Именно это я и имею ввиду. Откуда такие страхи? Или MS уже сама не может без Гашиш Кумаров и переживает о трудностях вхождения в свои собственные команды?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
IT>> Фактически, нас с вами назвали дебилами. Поздравляю!
AVK>Ты преувеличиваешь.
Андрей, это произошло! И то что вы там все стояли и смиренно в знак согласия махали головами только подтверждает этот факт. Как можно решать за пользователей что им нужно? У меня просто слов нет
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
IT>>> Фактически, нас с вами назвали дебилами. Поздравляю!
AVK>>Ты преувеличиваешь.
IT>Андрей, это произошло! И то что вы там все стояли и смиренно в знак согласия махали головами только подтверждает этот факт. Как можно решать за пользователей что им нужно? У меня просто слов нет
Может быть Майкрософт позиционирует шарп, как простой язык для "домохозяек"?
А CLI — это типа для продвинутых перцев?
Здравствуйте, VladD2, Вы писали:
AVK>> К примеру, не надо было объяснять что такое tuple и чем отличается от анонимных типов. VD>Так ты спросил почему они не содрали идею типлов (возможно адаптированную), а стали изобретать кривой велосипед?
У меня изначально создалось мнение, что это фичи не были развитием языка, а просто напросто фичи для поддержки запросов LINQ. Не менее(это еще можно стерпеть), но и самое главное не больше(вот тут я возмущен). Просто им нужно было продвинуть данную штуку, средств языка не хватало, вот и вделали разные фичи. Все новинки — полумеры. Нет ни одной цельной новинки.
AVK>>Не, не спрашивал. А смысл? По поводу AST-макросов он ответил весьма подробно. VD>Смысл глубочаший. Макросы только част прелеси этого языка. Язык очень сбалансированный и построен на точной мат.модели. Разработчики Шарпа могли бы много из него почерпнуть. А там и макросами прониклись бы.
А DSL tools тогда как продавать? Тут политика, блин. Коммерция.
Я так пониаю что C# 3 = Orcas = VS 2005 R2, верно?
Не затрагивалась ли политика лицензирования на R2 релиз? (Т.е. как R2 релиз будет предоставляться пользователям VS2005) И для висты абосолютно точно не будет рефреша CLR (по аналогии 1.0 ->1.1; 2.0->2.1) ?
Здравствуйте, IT, Вы писали:
AVK>>Ты преувеличиваешь.
IT>Андрей, это произошло!
Это произошло примерно 30 лет назад, когда программирование стало массовой профессией.
IT>И то что вы там все стояли и смиренно в знак согласия махали головами только подтверждает этот факт.
Во-первых ты не знаешь — махали ли мы головами или еще что делали. Во-вторых, что касаемо лично меня, меня языки заботят постольку-поскольку. Это всего лишь инструмент, и языковые проблемы это не самые страшные проблемы, которые передо мной стоят. Будет Nemerle доведен до промышленного состояния — отлично. Не будет в C# макросов никогда — тоже вобщем то не смертельно. Дебилом я от этого совсем не стану.
IT> Как можно решать за пользователей что им нужно?
А кто будет решать? Они выпускают собственный продукт и имеют право сами определять его возможности. Что тебя тут так волнует?
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>Вот и странно, что не понял зачем компилировать деревья выражений.
Ну может меня мой английский подвел.
AVK>> Вобще, как ни странно, мужик был грамотный и прекрасно ориентировался в современных языках.
VD>Действительно странно. На работе работают люди которые в ней что-то понимают.
В программировании это совсем нечастая ситуация. Ну и вобще то его работа не функциональные языки, а интеллисенс и рефакторинг шарпа в студии.
AVK>> К примеру, не надо было объяснять что такое tuple и чем отличается от анонимных типов.
VD>Так ты спросил почему они не содрали идею типлов (возможно адаптированную), а стали изобретать кривой велосипед?
Спросил. Ответа не получил.
AVK>>Не, не спрашивал. А смысл? По поводу AST-макросов он ответил весьма подробно.
VD>Смысл глубочаший. Макросы только част прелеси этого языка. Язык очень сбалансированный и построен на точной мат.модели. Разработчики Шарпа могли бы много из него почерпнуть. А там и макросами прониклись бы.
Влад, я не являюсь его (Nemerle) фанатом и у меня не было никакого желания заниматься PR, подобным тому что занимаешься ты. Если тебе кажется что это способно принести хоть какую то пользу, ты можешь написать ему на e-mail все что хочешь. Лично меня этот вопрос не интересует. Я и про макросы то спросил исключительно потому что ты очень желал услышать ответ. Парнишка был не столь скользкий как Хейлсберг, так что ответ ты услышал. На большее меня не хватило.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, GlebZ, Вы писали:
GZ>У меня изначально создалось мнение, что это фичи не были развитием языка, а просто напросто фичи для поддержки запросов LINQ. Не менее(это еще можно стерпеть), но и самое главное не больше(вот тут я возмущен).
Все еще печальнее. Прототип LINQ вобще не позволял его никак использовать прикладному программисту. DLINQ и XLINQ были вшиты в язык, а Standard Query Operators вобще отсутствовали. Так что теперешняя ситуация это не самое худшее что могло быть. Как минимум лямбды, expression tree и type inference (совсем не половинки) в сухом остатке наличествуют.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, PeterZT, Вы писали:
PZT>Я так пониаю что C# 3 = Orcas = VS 2005 R2, верно?
Не все так просто. Orcas это действительно следующая версия VS2005. Но главная фича отнюдь не новый компилятор, а поддержка WinFX. С# 3.0 же отдельный проект, просто его таки решили приурочить к Orcas.
PZT>Не затрагивалась ли политика лицензирования на R2 релиз? (Т.е. как R2 релиз будет предоставляться пользователям VS2005)
Скорее всего так же как и VS2003 пользователям VS2002.
PZT> И для висты абосолютно точно не будет рефреша CLR (по аналогии 1.0 ->1.1; 2.0->2.1) ?
Пока что даже слухов на эту тему нет. Вроде бы как когда то давно обещали в Висте 2.1. Если такое приключится, то видимо он и будет в Orcas. Если нет, то будет 2.0 с сервис-паками.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
IT>> Как можно решать за пользователей что им нужно?
AVK>А кто будет решать? Они выпускают собственный продукт и имеют право сами определять его возможности. Что тебя тут так волнует?
Безапелляционность. Они решили как нам лучше И главная причина — трудность вхождения в команду. Ну не смешно ли? Сколько я видел этих вхождений, тут либо есть вхождение, либо его нет, макросы на это никак повлиять не могут.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Безапелляционность. Они решили как нам лучше
Сдается мне, что они не решали, как нам лучше. Они решали, как ИМ лучше
Кстати, а никто не думал, что это самый Хобан просто не знал официальной точки зрения на вопрос и высказал свое имхо, возможно, первое, которое пришло в голову?
Здравствуйте, IT, Вы писали:
IT>Безапелляционность.
Не стоит судить по моим словам о тоне, которым это было произнесено. Я не точно цитировал. В оригинале расшаркиваний было более чем достаточно. Просто ночной перелет + разница в 3 часа несколько притупила мои мыслительные процессы и желания расписывать все не было.
IT> Они решили как нам лучше И главная причина — трудность вхождения в команду.
Опять же — даже я не писал что это причина главная.
IT> Ну не смешно ли? Сколько я видел этих вхождений, тут либо есть вхождение, либо его нет, макросы на это никак повлиять не могут.
Скажи, ты как считаешь — имеет смысл для одной команды регулярно менять язык, на котором они программируют, если этот язык без привязки к конкретным людям удобнее?
Видишь ли — я, например, не считаю, что, чем гибче язык, тем лучше. Тут, как и везде, наличествует tradeoff между сложностью и гибкостью. Где там золотая середина я не знаю, потому вполне допускаю, что можешь быть прав и ты и девелоперы из МС. Я единственно что точно знаю — никто никого дебилами не считает (хотя в отношении некоторых товарищей на этом форуме я уже так не уверен).
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, prVovik, Вы писали:
IT>>Безапелляционность. Они решили как нам лучше V>Сдается мне, что они не решали, как нам лучше. Они решали, как ИМ лучше
А что, кто то думал иначе?
V>Кстати, а никто не думал, что это самый Хобан просто не знал официальной точки зрения на вопрос и высказал свое имхо, возможно, первое, которое пришло в голову?
Видишь ли, он говорил от имени МС. А в этом случае, когда они высказывают личную точку зрения, они раз десять об этом предупредят. Например, дядечка из MSR, занимающийся С++, когда говорил о том что функциональное программирование лучший путь к поддержке multicore, специально упомянул о том что это ИМХО. В описываемом же случае никаких дисклеймеров не было. Ну и было бы странно, если бы program manager, ответственный за интеллисенс и рефакторинг LINQ, не знал бы причин основных решений по дизайну языка.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
IT>> Ну не смешно ли? Сколько я видел этих вхождений, тут либо есть вхождение, либо его нет, макросы на это никак повлиять не могут.
AVK>Скажи, ты как считаешь — имеет смысл для одной команды регулярно менять язык, на котором они программируют, если этот язык без привязки к конкретным людям удобнее?
Язык должен меняться не под людей, а под задачу. Меняется задача — меняется/настраивается язык.
AVK>Видишь ли — я, например, не считаю, что, чем гибче язык, тем лучше. Тут, как и везде, наличествует tradeoff между сложностью и гибкостью. Где там золотая середина я не знаю, потому вполне допускаю, что можешь быть прав и ты и девелоперы из МС.
Для меня решающий фактор один — простота конечного прикладного кода. Достигается ли это гибкостью языка, выбором архитектуры, паттернами, декомпозицией, рантайм или компайл тайм генерацией — это второй вопрос. Чаще всего это всё используется в комплексе. Но сегодня я лично вполне осознаю возможности применения тех же макросов и последствия этого применения. И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование. Единственное, что меня начинает смущать это то, что похоже кроме меня и ещё кучки людей это нафиг никому не нужно. В том числе и MS. А жаль.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
GZ>>У меня изначально создалось мнение, что это фичи не были развитием языка, а просто напросто фичи для поддержки запросов LINQ. Не менее(это еще можно стерпеть), но и самое главное не больше(вот тут я возмущен).
AVK>Все еще печальнее. Прототип LINQ вобще не позволял его никак использовать прикладному программисту. DLINQ и XLINQ были вшиты в язык, а Standard Query Operators вобще отсутствовали. Так что теперешняя ситуация это не самое худшее что могло быть. Как минимум AVK>лямбды,
Совсем без каких либо оптимизаций хотя бы на уровне expression lambda. Годится только для задания простых условий для функций высшего порядка. Хотя если считать что язык не функциональный, то могу это простить. AVK>expression tree
Единственное для чего — сериализовать некоторые условия(он не сериализует весь запрос, только лямбду) чтобы его смогли интерпретировать кто-то другой. И при этом без десериализации в код. Сам же возмущаешься. AVK>и type inference
Тоже Влад тут уже возмущался. Недоделанный какой-то. AVK>(совсем не половинки) в сухом остатке наличествуют.
Так что IMHO недоделочки все это.
Да, только что прочитал:
The next release is projected for this Spring. The DLINQ features we are targeting for the next preview are focused on support for inheritance, enhanced stored procedure support, and .Net function translation in queries. In addition we are targeting a database provider model that would provide an example of how to create a DLINQ provider for other databases. To be clear these are targeted items and may not make the preview if they aren't ready; but our current plan is to include them in the preview.
Здравствуйте, IT, Вы писали:
IT>Именно это я и имею ввиду. Откуда такие страхи? Или MS уже сама не может без Гашиш Кумаров и переживает о трудностях вхождения в свои собственные команды?
Тут приходится только гадать.
Жаль, что наши МВП-шники не задали самых интересных вопросов.
Возможно, что в МС просто не видят ниши продвинутых языков. А возожно они серьезно считают, что С++ является таким языком (лоби то у него ог-го-го).
ЗЫ
Однако слова того же Бокса о Лиспе внушают надежду, что в МС не все потеряно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Я об одном, ты про свое. Я говорю о статичности дженериков с точки зрения (веделяю слово не просто так!) процесса компиляции. То есть дженерики ничего не имеют общего с динамическими метапрограммами (макросами). Потому там рефакторинг и работает.
Само название — дженерики — говорит само за себя. Это средство обобщенного программирования. То есть полиморфизма.
Метапрограммированием конечно можно реализовать обобщенное программирование, но ставить знак равенства между этими вещами нельзя.
Собственно я уже говорил, что рефакторинг упирается не в мифические роблемы динамичности, а в банальную проблему модификации кода. Если переменная или свойство создаются метакодом во время компиляции, то ее рефакторинг мягко говоря затруднен. Однако, метакод может и не порождать сушьностей. В этом случае он прекрасно будет рефакториться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>У меня изначально создалось мнение, что это фичи не были развитием языка, а просто напросто фичи для поддержки запросов LINQ. Не менее(это еще можно стерпеть), но и самое главное не больше(вот тут я возмущен). Просто им нужно было продвинуть данную штуку, средств языка не хватало, вот и вделали разные фичи. Все новинки — полумеры. Нет ни одной цельной новинки.
Даже если так, все равно глупо делать недоработанные решения. Пусть анонимные типы происходят из Линков, но драли их явно из ФЯ. Почему было не взять полноценное решение?
GZ>А DSL tools тогда как продавать? Тут политика, блин. Коммерция.
Это откровенная ерунда. MS зарабатывает основные деньги на ОС. Ну, там серверы еще можно упомянуть, Офис... Но студия и фрэймвок для них это средство удержания рунка, а не коммерческие продукты в полном смысле этого слова. Потому и придуманы все эит Экспрессы.
Так что проблема тут в другом. Похоже что они действительно чтобы реализовать функциональность линка решили взять идеи из ФЯ, Смолтока и т.п., но потом, то ли они сами испугались того, что они за монстра могут породить, то ли их архитекторы безбожно тупят. Оба расклада не радуют.
ЗЫ
С другой сторонры хоть какое-то развитие. В С++ похоже и того не появится.
Но если дела пойдут так и далее, то Р-Шарпы и Немерлы окажутся очень даже востребованны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Действительно странно. На работе работают люди которые в ней что-то понимают.
AVK>В программировании это совсем нечастая ситуация.
Ты меня пугашь.
AVK>Ну и вобще то его работа не функциональные языки, а интеллисенс и рефакторинг шарпа в студии.
Дык такие люди должны понимать в теории компиляторов все. И знать всю историю ЯП с самыми экзотическими расшерениями.
AVK>Спросил. Ответа не получил.
Ясно. Это еще больше подтверждает версию о политике расчета на быдлокодера и боязни их упустить.
AVK>Влад, я не являюсь его (Nemerle) фанатом
Я вообще фанатом не являюсь. Я просто умею оценивать вещи по достоинству.
AVK>и у меня не было никакого желания заниматься PR, подобным тому что занимаешься ты.
Пиарить и не надо. Но спросить видели ли, и если видели, то каково мнение, или если не видели предложить посмотреть, можно было. Хуже им от этого не станет. Скорее станет хуже от того, что они не посмотрят достойную реализацию. Причем хуже станет нам.
AVK> Если тебе кажется что это способно принести хоть какую то пользу, ты можешь написать ему на e-mail все что хочешь.
Ну, кинь мыло... попробую как-нить на досуге черкнуть...
AVK> Лично меня этот вопрос не интересует. Я и про макросы то спросил исключительно потому что ты очень желал услышать ответ.
В таком виде смысла вопрос предствлят не много. Я их прекрасно понимаю. Если у тебя нет цельной идеи, то самое простое отмазаться. Другое дело, когда имеется продуманная цельная идея.
AVK> Парнишка был не столь скользкий как Хейлсберг, так что ответ ты услышал. На большее меня не хватило.
Да тут похоже и время сиграло. Ведь им релизиться скоро. А когда ты с Хейсбергом говорил они еще ничего толком не знали.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Андрей, это произошло! И то что вы там все стояли и смиренно в знак согласия махали головами только подтверждает этот факт. Как можно решать за пользователей что им нужно? У меня просто слов нет
Слава богу это рынок. Если у МС не хватит ума, то его хватит у кого-нибудь еще. Слепость МС только замедлит процесс. А там глядишь и слепота пройдет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Видишь ли — я, например, не считаю, что, чем гибче язык, тем лучше. Тут, как и везде, наличествует tradeoff между сложностью и гибкостью. Где там золотая середина я не знаю, потому вполне допускаю, что можешь быть прав и ты и девелоперы из МС. Я единственно что точно знаю — никто никого дебилами не считает (хотя в отношении некоторых товарищей на этом форуме я уже так не уверен).
Единственый факт заключаетсая в том, что и ты, и я, и ИТ использовали и используем разные мелкие и не очень ДСЛ-и в своих проектах. За неимением качественных средств их создания и отладки мы используем разные мало приспособленные для этого вещи. Лично ты, например, используешь ХСЛТ. ИТ вообще до Эмита докатился.
То есть потребность есть. И ответ орла из МС кроме как отмазкой назвать нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Язык должен меняться не под людей, а под задачу. Меняется задача — меняется/настраивается язык.
Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?
IT>Для меня решающий фактор один — простота конечного прикладного кода.
Это многофакторный параметр.
IT>И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование.
Олично. А я не вижу. Ты считаешь, что правда за тобой?
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, GlebZ, Вы писали:
GZ>Совсем без каких либо оптимизаций хотя бы на уровне expression lambda.
Кто такой expression lambda и о каких оптимизациях речь?
GZ>Единственное для чего — сериализовать некоторые условия(он не сериализует весь запрос, только лямбду) чтобы его смогли интерпретировать кто-то другой. И при этом без десериализации в код. Сам же возмущаешься.
Ссылку в студию, где я этим возмущался. Я лично не вижу в этом особой нужды.
AVK>>и type inference GZ>Тоже Влад тут уже возмущался. Недоделанный какой-то.
И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость.
AVK>>(совсем не половинки) в сухом остатке наличествуют. GZ>Так что IMHO недоделочки все это.
Ну, таким манером недоделками можно назвать что угодно.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
AVK>>В программировании это совсем нечастая ситуация.
VD>Ты меня пугашь.
А я то тут при чем? Не я придумал этот мир.
AVK>>Влад, я не являюсь его (Nemerle) фанатом
VD>Я вообще фанатом не являюсь.
Извини, но когда 100% топиков в философии с твоим участием превращаются в обсуждение Nemerle, других выводов я сделать не могу.
AVK>>и у меня не было никакого желания заниматься PR, подобным тому что занимаешься ты.
VD>Пиарить и не надо. Но спросить видели ли, и если видели, то каково мнение, или если не видели предложить посмотреть, можно было. Хуже им от этого не станет. Скорее станет хуже от того, что они не посмотрят достойную реализацию. Причем хуже станет нам.
Уж если проект получил грант от МС, то уж знают о нем они наверняка, не переживай.
AVK>> Если тебе кажется что это способно принести хоть какую то пользу, ты можешь написать ему на e-mail все что хочешь.
VD>Ну, кинь мыло... попробую как-нить на досуге черкнуть...
http://blogs.msdn.com/lukeh/contact.aspx
AVK>> Лично меня этот вопрос не интересует. Я и про макросы то спросил исключительно потому что ты очень желал услышать ответ.
VD>В таком виде смысла вопрос предствлят не много. Я их прекрасно понимаю. Если у тебя нет цельной идеи, то самое простое отмазаться.
Ну тогда точно бессмысленно спрашивать. Таким манером любой ответ, кроме того что Nemerle восхитителен, будет воспринят как отмазка.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?
Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу".
Первое болие чем реально, а второе несколько болие проблематично но тоже реально оссбенно если библиотеки реально сократят сроки разработки.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Извини, но когда 100% топиков в философии с твоим участием превращаются в обсуждение Nemerle, других выводов я сделать не могу.
100% твоих сообщений о дотнете и МС. Делаем выводы о твоем фанатизме?
Сейчас мне интересна тема Немерла. Только и всего.
Фанатизм — это слепая вера. Вряд ли можно назвать мой выбор верой и темболее слепой. Скорее верой можно назвать поддержку действий одной компании как бы эти действия не шли в разрез с чаяниями их потребителей.
Так что предлагаю, не развивать тему обсуждения чужой личности.
AVK>Уж если проект получил грант от МС, то уж знают о нем они наверняка, не переживай.
Зная размеры МС не удивлюсь тому, что одна рука не знает, что делает другая.
Думаешь он ответит на вопрос заданный незнамо кем?
VD>>В таком виде смысла вопрос предствлят не много. Я их прекрасно понимаю. Если у тебя нет цельной идеи, то самое простое отмазаться.
AVK>Ну тогда точно бессмысленно спрашивать. Таким манером любой ответ, кроме того что Nemerle восхитителен, будет воспринят как отмазка.
Причем тут "Nemerle восхитителен"? Вчитайся в мои слова. У тебя не было такого, что другие предлагали в общем-то хорошую идею, но ты не видел того, как эту идею красиво интегрировать в свой продукт? Вот такая же фигня у компиляторостроителей. Им больше всего не хочется делать довески. Им нужны чистые и красивые решения. Только тогда язык будет чистым и красивым. Так вот изучение чужих чистых решений дает большой потенциал для размышлений.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>и type inference GZ>>Тоже Влад тут уже возмущался. Недоделанный какой-то.
AVK>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость.
Почему же в конце то? А то, что в C# 3.0 при инициализации коллекций вывод типов может делаться очень далеко от самого объявления — это тоже прблема?
AVK>>>(совсем не половинки) в сухом остатке наличествуют. GZ>>Так что IMHO недоделочки все это.
AVK>Ну, таким манером недоделками можно назвать что угодно.
Анонимные типы никак по другому язык не поворачивается назвать. А ведь все что нужно сделать — это создать синтаксис декларации анонимного типа и средства для распаковки анонимного объекта. Смотри насколько это интуитивно выклядит в паре с достойным выводом типов:
GetData(id : int) : IEnumeramle<string * string>
{
ExecuteReaderLoop ("SELECT firstname, lastname FROM employee WHERE firstname = $id", dbcon,
{
yield (firstname, lastname);
});
}
...
foreach ((firstname, lastname) in GetData(1))
WriteLine($"First name: $firstname Last name: $lastname");
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование.
Подумалось. Наверно не верно ставить их в линейку. Это технологии которые прекрасно дург с другом совмещаются. Так что стрелочки могут определять не равитие а последовательность появлений. А линейка развития должна выглядить так:
структурное программирование
+ ООП
+ компонентное программирование
+ метапрограммирование
Причем этот список будет только пополняться. В будущем появится еще параллельное программирование и т.п.
Более того все это уже наверно даже появилось, но в лабараториях эксперементаторов. А мы перчисляем то что уже пришло в мэйнстрим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
AVK>>Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте? WH>Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу".
Я не подменял. Я первого вопроса никогда не задавал.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>Почему же в конце то? А то, что в C# 3.0 при инициализации коллекций вывод типов может делаться очень далеко от самого объявления — это тоже прблема?
Далеко? По моему там все ограничено одним выражением.
AVK>>Ну, таким манером недоделками можно назвать что угодно.
VD>Анонимные типы никак по другому язык не поворачивается назвать.
Влад, ты внимательно читал мои сообщения? Судя по всему нет.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
AVK>>Извини, но когда 100% топиков в философии с твоим участием превращаются в обсуждение Nemerle, других выводов я сделать не могу.
VD>100% твоих сообщений о дотнете и МС. Делаем выводы о твоем фанатизме?
Нет, делаем выводы о твоей правдивости.
И, собственно, речь не о том, что чьи то сообщения о чем то, а о том что любой вопрос ты превращаешь в обсуждение Nemerle. Помнишь как СГ на каждый вопрос находил единственный ответ — Oberon. Ты сейчас делаешь тоже самое.
Вобщем неважно. Важно другое — лично я не испытываю жуткого интереса к Nemerle, чтобы спрашивать о нем всегда и везде. Да и не только спрашивать, потому что собственно я вопроса пока даже не услышал, а агитировать за него.
VD>Сейчас мне интересна тема Немерла. Только и всего.
А мне нет, только и всего.
VD>Так что предлагаю, не развивать тему обсуждения чужой личности.
Ты неверно воспринял исходный топик. Это не обсуждение твоей личности, это скорее обсуждение моей личности.
AVK>>http://blogs.msdn.com/lukeh/contact.aspx
VD>Думаешь он ответит на вопрос заданный незнамо кем?
Тогда пиши мне, я попытаюсь переправить.
AVK>>Ну тогда точно бессмысленно спрашивать. Таким манером любой ответ, кроме того что Nemerle восхитителен, будет воспринят как отмазка.
VD>Причем тут "Nemerle восхитителен"?
Ну а какой бы ответ тебя устроил, кроме абсолютно положительного?
VD> Вчитайся в мои слова. У тебя не было такого, что другие предлагали в общем-то хорошую идею, но ты не видел того, как эту идею красиво интегрировать в свой продукт? Вот такая же фигня у компиляторостроителей. Им больше всего не хочется делать довески.
На этот вопрос ты ответ получил — технических причин нет или они, по крайней мере, не основные.
VD> Им нужны чистые и красивые решения. Только тогда язык будет чистым и красивым. Так вот изучение чужих чистых решений дает большой потенциал для размышлений.
Т.е. ты предлагаешь мне поучить их, как им следует работать?
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
WH>>Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу". AVK>Я не подменял. Я первого вопроса никогда не задавал.
Скажи, ты как считаешь — имеет смысл для одной команды регулярно менять язык, на котором они программируют, если этот язык без привязки к конкретным людям удобнее?
А это что за вопрос?
К томуже тут нужно говорить не о смене языка, а о настройке языка для некоторых задач. А в большинстве случаев Nemerle со стандартными макросами будет работать болие чем нормально. Но в некоторых случаях когда жареный петух... Например помнишь то попадалово с с реализацией иерархии контролов? Там макросы Nemerle решили бы все проблемы.
А Гашиш Кумарам не важно инидйского или местного разлива писать или использовать левые макросы можно просто запретить.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Ты подменил вопрос с "немного изменить язык под задачу" на "сменить платформу". AVK>>Я не подменял. Я первого вопроса никогда не задавал. WH>
Скажи, ты как считаешь — имеет смысл для одной команды регулярно менять язык, на котором они программируют, если этот язык без привязки к конкретным людям удобнее?
Ну и? Где там про "немного изменить"? Я вобщем то спрашивал про разные языки.
WH>К томуже тут нужно говорить
Кому нужно?
WH> не о смене языка, а о настройке языка для некоторых задач. А в большинстве случаев Nemerle со стандартными макросами будет работать болие чем нормально. Но в некоторых случаях когда жареный петух...
Видишь ли, я сейчас не хочу спорить о предмете. Хотя бы потому что лично я в этом вопросе не компетентен. Я всего лишь хочу показатью. что точка зрения МС имеет право на существование и это тнюдь не отмазка. Правильного же ответа на вопрос я не знаю.
WH> Например помнишь то попадалово с с реализацией иерархии контролов? Там макросы Nemerle решили бы все проблемы.
И миксины тоже.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
IT>>Язык должен меняться не под людей, а под задачу. Меняется задача — меняется/настраивается язык.
AVK>Я не про это спрашивал. Я про другое — считаешь ли ты допустимым вне контекста Nemerle, сменить для команды, писавшей пару лет на C#, язык на Java, только потому что есть ряд библиотек на ней, которые будут удобны в текущем проекте?
Я об этом даже речи не вёл и вне контекста ситуации на этот вопрос нельзя ответить. Но если тебя интересует однозначный ответ, то скорее нет, чем да. Да и к макросам и DSL это отношения не имеет. В их случае все библиотеки и даже привычная среда остаются. Меняется/модифицируется язык под конкретную задачу.
Как я понимаю, ты опасаешься, что "писатели" с большой буквы "ПЫ" на макросах могут такого понаписывать, что потом не разберёшься. Так вот я тебя могу успокоить. Они и без макросов отлично это умеют делать. Порой приходится месяцами убеждать и показывать на примерах что так и так делать нельзя. Про 77 классов, имплементирующих одностраничный отчёт я уже здесь рассказывал не раз. Про "медленность" исключений и замену их на коды возврата тоже. Всё это не имеет к метапрограммированию никакого отношения. Это проблема отсутствия либо опыта, либо мозгов помноженная на гипертрофированное самомнение.
IT>>Для меня решающий фактор один — простота конечного прикладного кода.
AVK>Это многофакторный параметр.
Именно. Заметь, я не говорю про библиотечный код или код фреймворков. Этот код возможно своей сложностью и нетривиальностью как раз и должен обеспечивать простоту прикладного кода. А вот прикладной может и должен являться мерилом правильности выбора как архитектуры так и качества библиотек и фреймворков. Особенно это показательно на больших проектах. Если большая часть кода копипейстится, то архитектору нужно сначала пойти доучиться в школу и быть при этом хорошим мальчиком.
IT>>И вижу, что это может продолжить линейку развития структурное программирование -> ООП -> компонентное программирование -> метапрограммирование.
AVK>Олично. А я не вижу. Ты считаешь, что правда за тобой?
Я пытаюсь это понять. В моих приложениях рантайм генерация кода занимает весьма заметную роль. Её замена на compile-time была бы идеальным решением и закрыла бы некоторые сопутствующие рантайм генерации проблемы. При этом аргументы типа "трудность вхождения в команду" менять просто бесят О чём вообще идёт речь те кто это говорит понимают? Вот примерчик из пока не доделанного demo для bltoolkit:
using System;
using System.ComponentModel;
using BLToolkit.Mapping;
using BLToolkit.Validation;
namespace BLToolkit.Demo.ObjectModel
{
[MapField("PersonID", "ID")]
public abstract class Person : BizEntity
{
[MaxLength(50), Required] public abstract string LastName { get; set; }
[MaxLength(50), Required] public abstract string FirstName { get; set; }
[MaxLength(50)] public abstract string MiddleName { get; set; }
[ Required] public abstract Gender Gender { get; set; }
[MapIgnore]
public string FullName
{
get
{
return string.Format(
string.IsNullOrEmpty(MiddleName)? "{2}, {0}": "{2}, {0} {1}.",
FirstName, MiddleName, LastName);
}
}
}
}
Класс поддерживает AcceptChanges, RejectChanges, IsDirty, валидацию и прочую байду. Генерируется в рантайме. Трудно войти? Что тут непонятного?
Вот возможный DataAccessor:
public abstract class PersonAccessor : DataAccessor<Person>
{
[SqlQuery("SELECT * FROM Person WHERE LastName = @lastName")]
public abstract List<Person> SelectByLastName(string lastName);
[SqlQuery("SELECT * FROM Person WHERE {0} = @value")]
public abstract List<Person> SelectBy([Format] string fieldName, string value);
[SqlQuery("SELECT TOP {0} * FROM Person WHERE LastName = @lastName")]
public abstract List<Person> SelectByLastName(string lastName, [Format(0)] int top);
}
Возможный, а не реальный, потому что в примере пока всё обходится базовыми CRUDL операциями, а для них кода совсем не требуется. Какие здесь трудности с вхождением?
А вот полный код формы редактирования объекта Person:
using System;
using BLToolkit.Demo.ObjectModel;
namespace BLToolkit.Demo.Forms
{
public partial class EditPersonForm : BizEntityForm, IBizEntityForm<Person>
{
public EditPersonForm()
{
InitializeComponent();
}
public void SetBizEntity(Person person)
{
personBinder.Object = person;
}
}
}
Простите, короче не получается из-за ограничений дизайнера форм и дженериков. Форма, кстати, умеет подсвечивать невалидные поля, поля у которых установлен флаг IsDirty, рисовать тултипы с информацией о валидации, обрабатывать ошибки и т.п. Вызов её делается следующим образом:
// Редактирование записи.
//
BizEntityForm.Edit<EditPersonForm, Person>(person, delegate(Person p)
{
new PersonManager().Update(p);
});
// Добавление новой.
//
Person person = BizEntityForm.EditNew<EditPersonForm, Person>(delegate(Person p)
{
new PersonManager().Insert(p);
});
Код PersonManager не привожу, т.к. это пока pass-through класс.
Это практически весь прикладной код, реализующий поддержку класса Person в приложении. Любой вменяемый WinForms девелопер, только что вошедший в команду, уже через два дня будет печь такие формы как пирожки. И не надо убеждать меня в обратном. А если бы сюда прикрутить метапрограммирование, то всё это хозяйство можно было бы ещё упростить. Ушли бы абстрактные классы и возможно получилось бы обойти ограничения WinForms с дженериками и убрать из формы метод SetBizEntity и лишний интерфейс.
Вот теперь ты мне ответь, пожалуйста. Всё это бред и так в жизни не бывает? Это так трудно понять и ещё труднее использовать? И главное, что здесь нет места метапрограммированию? При этом заметь, речь идёт о самой типичной задаче.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Подумалось. Наверно не верно ставить их в линейку. Это технологии которые прекрасно дург с другом совмещаются. Так что стрелочки могут определять не равитие а последовательность появлений.
OK, с этим спорить я не буду
VD>Более того все это уже наверно даже появилось, но в лабараториях эксперементаторов. А мы перчисляем то что уже пришло в мэйнстрим.
Именно о мейнстриме и идёт речь. Тот же ООП стал доступен широким массам только благодаря C++, хотя C++ был далеко не первый язык с классами.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Даже если так, все равно глупо делать недоработанные решения. Пусть анонимные типы происходят из Линков, но драли их явно из ФЯ. Почему было не взять полноценное решение?
Насколько я правильно понял tuple, он при реализации в чистом виде подразумевают динамическую типизацию. А они сделали строготипизированную приблуду. То ли обленились, то ли политика такая.
Consider anonymous types to be a compile-time feature to create a strongly typed class for you when and if you need it.
There is no inclination to reduce the strongly-typed nature of C#. If anything, LINQ is more about increasing the amount of strong-typing that happens in your code.
Отсюда
Но почему они ограничились именно функцией? хз.
GZ>>А DSL tools тогда как продавать? Тут политика, блин. Коммерция. VD>Это откровенная ерунда. MS зарабатывает основные деньги на ОС. Ну, там серверы еще можно упомянуть, Офис... Но студия и фрэймвок для них это средство удержания рунка, а не коммерческие продукты в полном смысле этого слова. Потому и придуманы все эит Экспрессы.
Есть еще всякие Axapta с Navision. Есть у Microsoft достаточно много заказух. Есть еще огромный корпоративный рынок с которого Oracle c IBM многомиллиардные бабки сколачивает. И на котором властвует Java, в котором набор стандартов для таких решений значительно больше и удобнее.
VD>Так что проблема тут в другом. Похоже что они действительно чтобы реализовать функциональность линка решили взять идеи из ФЯ, Смолтока и т.п., но потом, то ли они сами испугались того, что они за монстра могут породить, то ли их архитекторы безбожно тупят. Оба расклада не радуют.
Я думаю здесь постарались маркетологи. Отсутсвие стандарта на persisting objects действительно сильно влияет на рынок. Я сам часто лазию по JSR и, стыдно сказать, завидую. Хорошие или плохие стандарты, это уже другой вопрос. Они есть, есть их реализации, а недостатки или достоинства языка меньше влияют на применимость, сколько отсутвие стандартов и библиотек.
Здравствуйте, AndrewVK, Вы писали:
GZ>>Совсем без каких либо оптимизаций хотя бы на уровне expression lambda. AVK>Кто такой expression lambda и о каких оптимизациях речь?
Это те которые не statement. Об оптимизациях говорить не буду, потому как не спец. Если брать функциональные языки, то там математически доказанных оптимизаций до фигищи. Мне просто это мало интересно. Если хочешь, спроси у них на форуме, они накатают вагон и маленькую тележку.
GZ>>Единственное для чего — сериализовать некоторые условия(он не сериализует весь запрос, только лямбду) чтобы его смогли интерпретировать кто-то другой. И при этом без десериализации в код. Сам же возмущаешься. AVK>Ссылку в студию, где я этим возмущался. Я лично не вижу в этом особой нужды.
Хитро. Дескать я спросил, только чтобы отмазаться. Охотно верю что ты даже не обращаешь на него внимания, поскольку пользовать его и не собираешься. В нынешнем виде, действительно, плохо применимо. Хотя кое что я нашел.
Фактически мне показалось странным ответ Хобана. У них есть одна хитрость. Вместе с Linq они поставляют некоторый пример Espresso. Это как раз динамический интерпретатор(насколько я в нем разобрался) запросов. Почему они его вшпилили именно как sample, а не API, не знаю. Подозреваю какую-то хитрость. Но иметь такое API — надо, а в виде достаточно сложного сэмпла, это не есть гуд. Он врядли будет хорошо документирован. К тому же мне понадобилось много времени, чтобы вообще обратить на него внимание. Вобщем, то что это не API — недоделка.
AVK>>>и type inference GZ>>Тоже Влад тут уже возмущался. Недоделанный какой-то. AVK>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость.
Не соглашусь. Во многом эта ситуация похожа на ситуацию с generic. Мы не знаем что это за тип, нас волнует только логика обработки. А ежели где напакостничили, то компилятор нам об этом сообщит. Или надо будет смотреть по коду что это за тип.
AVK>>>(совсем не половинки) в сухом остатке наличествуют. GZ>>Так что IMHO недоделочки все это. AVK>Ну, таким манером недоделками можно назвать что угодно.
Когда есть с чем сравнивать, определить доделанность той или иной фичи не представляет труда.
Здравствуйте, AndrewVK, Вы писали:
AVK>Далеко? По моему там все ограничено одним выражением.
Забавный аргумент. В Немерле тело любой функции — это одно выражение.
Но вот оно может быть довольно большим. Точно так же большим может быть и инициализатор в C#.
VD>>Анонимные типы никак по другому язык не поворачивается назвать.
AVK>Влад, ты внимательно читал мои сообщения? Судя по всему нет.
Внимательно. И из них явно следует, что в релиз поподет эта недоделка:
2) По поводу недоступности анонимных типов вне контекста функции: проблема известна, но по поводу ее решения он ничего сказать не смог. Боюсь, в релизе linq все останется как есть сейчас.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>100% твоих сообщений о дотнете и МС. Делаем выводы о твоем фанатизме?
AVK>Нет, делаем выводы о твоей правдивости.
Да? А может о твоей?
AVK>И, собственно, речь не о том, что чьи то сообщения о чем то, а о том что любой вопрос ты превращаешь в обсуждение Nemerle. Помнишь как СГ на каждый вопрос находил единственный ответ — Oberon. Ты сейчас делаешь тоже самое.
Учись оппелировать к словам, а не личности.
AVK>Вобщем неважно. Важно другое — лично я не испытываю жуткого интереса к Nemerle,
И на этом основании тебя раздражает любая информация о нем?
Прэлесно.
AVK> чтобы спрашивать о нем всегда и везде. Да и не только спрашивать, потому что собственно я вопроса пока даже не услышал, а агитировать за него.
Не спрашивай. Но воспринимай нормально когда тебе при обсуждении недоделок в одном языке указывают на то как они могут быть реализованы в другм. И не злись когда видишль людей которые увлечены тем, что тебя не интересует.
VD>>Сейчас мне интересна тема Немерла. Только и всего.
AVK>А мне нет, только и всего.
Здорово. И почему ты считашь нормальным высказывать другим фэ по поводу того что они увлечены чем-то другим? Да еще ири этом постоянно переходить на личности.
VD>>Так что предлагаю, не развивать тему обсуждения чужой личности.
AVK>Ты неверно воспринял исходный топик. Это не обсуждение твоей личности, это скорее обсуждение моей личности.
Я не про тему. Я про твои слова обо мне.
VD>>Думаешь он ответит на вопрос заданный незнамо кем?
AVK>Тогда пиши мне, я попытаюсь переправить.
ОК.
AVK>Ну а какой бы ответ тебя устроил, кроме абсолютно положительного?
Меня устроил бы анализ. Любой. Главное, чтобы он был максимально аргументирован.
AVK>На этот вопрос ты ответ получил — технических причин нет или они, по крайней мере, не основные.
Еще раз. Вопрос в такой формулировке интереса не имеет. Человк мог не знать о том, что макросы подчиняются областям видимости и регулируются подключаемыми сборками.
Без этой информации я возможно тоже посомневался бы.
AVK>Т.е. ты предлагаешь мне поучить их, как им следует работать?
Тебе нужно переводить на русский с русского? Думаю, нет. Тогда разреши мне процетировать самого себя:
Не спрашивал его отношение Немерлу? Они его вообще смотрели?
Не думаю, что вопрос "Что вы думаете по поводу Немерле?" может быть расценен как поучение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Видишь ли, я сейчас не хочу спорить о предмете. Хотя бы потому что лично я в этом вопросе не компетентен. Я всего лишь хочу показатью. что точка зрения МС имеет право на существование и это тнюдь не отмазка. Правильного же ответа на вопрос я не знаю.
К ответу
IT мне пожалуй нечего добавить.
WH>> Например помнишь то попадалово с с реализацией иерархии контролов? Там макросы Nemerle решили бы все проблемы. AVK>И миксины тоже.
Я бы предпочел макросы. Ибо миксины через макросы реализуются на раз, а вот макросы через миксины...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Я об этом даже речи не вёл и вне контекста ситуации на этот вопрос нельзя ответить. Но если тебя интересует однозначный ответ, то скорее нет, чем да. Да и к макросам и DSL это отношения не имеет.
Имеет. Потому что на данном этапе mainstream-языки разделяет в основном поддержка парадигм и набор сахара. Надеюсь ни у кого не вызывает сомнения в том, что на Nemerle можно эмулировать довольно широкий спектр языков? C# уже эмулируется, с Питоном, насколько я понимаю, тоже особых проблем нет, Java тоже без проблем, С++ в той или иной мере, ограничиваемой safe-контекстом. Ну и т.д.
Теперь возвращаясь к моему вопросу — очевидно, что язык программирования, помимо основной своей задачи, является еще и средством коммуникации разработчиков в команде. Даже в случае применения нестандартных техник лично я наблюдал проблемы понимания кода одних членов команды другими. Не думаю что кто то будет спорить, что возможностей по созданию непонимания у Nemerle существенно больше.
Твоя точка зрения, как я понимаю, состоит в том, что разработчики достаточно благоразумны, чтобы использовать только те возможности, которые не создадут проблем, сопоставимых с гусем. Вот в это то я и не верю. Т.е. конечно разработчики не дебилы конечно, но процентов 90, если не меньше, не компетентны в вопросах дизайна ЯП. Опять же, я бы поверил что это не так, однако же ряд примеров, в том числе и ругаемый здесь С++, скорее убеждают меня в моей правоте, нежели наоборот.
IT>Как я понимаю, ты опасаешься, что "писатели" с большой буквы "ПЫ" на макросах могут такого понаписывать, что потом не разберёшься. Так вот я тебя могу успокоить. Они и без макросов отлично это умеют делать.
Вопрос в соотношении. Как ни странно, но процент юзабельных библиотек Java существенно выше онных для C# или С++. И еще один момент, немаловажный при борьбе с такими орлами — рефакторинг. Алгоритм универсальный для макросов построить невозможно, следовательно как то надо придумывать обходные пути. А здесь я пока ничего хорошего в макросах не вижу.
IT>Именно. Заметь, я не говорю про библиотечный код или код фреймворков. Этот код возможно своей сложностью и нетривиальностью как раз и должен обеспечивать простоту прикладного кода. А вот прикладной может и должен являться мерилом правильности выбора как архитектуры так и качества библиотек и фреймворков. Особенно это показательно на больших проектах. Если большая часть кода копипейстится, то архитектору нужно сначала пойти доучиться в школу и быть при этом хорошим мальчиком.
Если говорить о прикладных DSL, то там крайне важен жесточайший контроль за прикладным кодом. В случае прикладных декларативных DSL мне понятны пути, как этого достичь. А в случае Nemerle?
AVK>>Олично. А я не вижу. Ты считаешь, что правда за тобой?
IT>Я пытаюсь это понять. В моих приложениях рантайм генерация кода занимает весьма заметную роль.
В моих иногда тоже. Только решает она не задачи дизайна, а задачи перформанса. Да, мне был бы интересен фреймворк для более удобной кодогенерации (я, собственно уже писал о том, что генератор на базе Nemerle (как исходников, так и IL) меня интересует куда больше, нежели макросы), но речь то именно о макросах, а не о Nemerle в целом.
Есть еще АОП и похожие на него технологии, но здесь, во-первых мне кажется что compile time reflection чуть более контроллируема (не меняет синтаксиса языкам), а во-вторых, как я уже писал, они часто связаны с деплойментом, а значит ряд информации только на этапе деплоймента и известен, что налагает ограничения на использование compile time технологий.
Наконец есть еще задача генерации объектных моделей с большим количеством однотипных объектов, но здесь, опять же, ничего такого, ради чего стоило бы кардинально менять язык, Nemerle не привносит.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
AVK>>Влад, ты внимательно читал мои сообщения? Судя по всему нет.
VD>Внимательно. И из них явно следует, что в релиз поподет эта недоделка: VD>
2) По поводу недоступности анонимных типов вне контекста функции: проблема известна, но по поводу ее решения он ничего сказать не смог. Боюсь, в релизе linq все останется как есть сейчас.
Чуть ниже. Когда я говорил что определенный сухой остаток есть, я перечислял технологии, которые, по моему мнению, являются вполне полезными и вне DLINQ сотоварищи. Анонимные тьипы в этот перечень не входили.
Что касается убогости анонимных типов вне контекста декларативных запросов, то тут я полностью с тобой согласен. Более того, с этим согласны и товарищи из МС, о чем я писал.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, GlebZ, Вы писали:
AVK>>Кто такой expression lambda и о каких оптимизациях речь? GZ>Это те которые не statement.
Опять непонятно. Плиз, открой спецификацию C# 3.0 и используй термины оттуда, иначе тебя сложно понимать. expression lambda, которые не statement, это, видимо, что то потрясающее, но мне не известное.
GZ> Об оптимизациях говорить не буду, потому как не спец. Если брать функциональные языки, то там математически доказанных оптимизаций до фигищи. Мне просто это мало интересно. Если хочешь, спроси у них на форуме, они накатают вагон и маленькую тележку.
Я много оптимизаций примерно представляю. О каких конкретно идет речь и при чем здесь LINQ?
AVK>>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость. GZ>Не соглашусь. Во многом эта ситуация похожа на ситуацию с generic. Мы не знаем что это за тип, нас волнует только логика обработки. А ежели где напакостничили, то компилятор нам об этом сообщит. Или надо будет смотреть по коду что это за тип.
О, последнее предложение ключевой момент.
AVK>>Ну, таким манером недоделками можно назвать что угодно. GZ>Когда есть с чем сравнивать, определить доделанность той или иной фичи не представляет труда.
Я еще раз повторю — таким манером недоделанным можно назвать любую фичу того же C# 2.0. Присобачить свои аргументы к любой из его фич и посмотреть на результат ты можешь самостоятельно.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>Да? А может о твоей?
...
VD>Учись оппелировать к словам, а не личности.
...
VD>И на этом основании тебя раздражает любая информация о нем? VD>Прэлесно.
...
VD>Не спрашивай. Но воспринимай нормально когда тебе при обсуждении недоделок в одном языке указывают на то как они могут быть реализованы в другм. И не злись когда видишль людей которые увлечены тем, что тебя не интересует.
...
VD>Здорово. И почему ты считашь нормальным высказывать другим фэ по поводу того что они увлечены чем-то другим? Да еще ири этом постоянно переходить на личности.
А, ну понеслась. Спорьте, мужчина, без меня. (и этот человек обвиняет меня в переходе на личности )
VD>Меня устроил бы анализ. Любой. Главное, чтобы он был максимально аргументирован.
Анализ. В рамках устного общения в режиме цейтнота времени? Ты видимо чего то не понимаешь — описываемый разговор происходил в рамках доклада по C# 3.0 и я и так отнял минут 10 от часового доклада на свои вопросы.
VD>Еще раз. Вопрос в такой формулировке интереса не имеет.
Для меня имеет.
AVK>>Т.е. ты предлагаешь мне поучить их, как им следует работать?
VD>Тебе нужно переводить на русский с русского? Думаю, нет. Тогда разреши мне процетировать самого себя: VD>
Не спрашивал его отношение Немерлу? Они его вообще смотрели?
Тогда позволь переадресовать к тебе твои претензии. Я уже писал — лично мне этот вопрос абсолютно не интересен. Меня интересуют технические вопросы (притом больше с прицелом на дизайн информационных систем, нежели на кодинг), а не отношение конкретного перца из МС к конкретным разработкам.
VD>Не думаю, что вопрос "Что вы думаете по поводу Немерле?" может быть расценен как поучение.
Только вот этот вопрос легко допускает непринужденный уход от ответа, потому что он сильно неконкретен.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, WolfHound, Вы писали:
AVK>>И миксины тоже. WH>Я бы предпочел макросы. Ибо миксины через макросы реализуются на раз, а вот макросы через миксины...
А я миксины, потому что мне, на моих задачах, их хватит выше крыши, а за дополнительную гибкость я платить не желаю.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А я миксины, потому что мне, на моих задачах, их хватит выше крыши, а за дополнительную гибкость я платить не желаю.
Чем платить?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
AVK>>А я миксины, потому что мне, на моих задачах, их хватит выше крыши, а за дополнительную гибкость я платить не желаю. WH>Чем платить?
Считаешь, что таки кое где бывает бесплатный сыр ака silver bullet?
P.S. Не сочти за демагогию, ответ на твой вопрос уже содержится в моих постах.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Считаешь, что таки кое где бывает бесплатный сыр ака silver bullet?
Я так не считаю. Рано или позно найдется монстр которого этой пулей не убить. Но эта пуля легко убивает всех монстров которых убивает C# и еще кучу которых C# даже поцарапать не может.
Вобщем лично я предпочту выходить на охоту на монстров с максимально мощными пулями ибо в этом случае вероятность нарваться на неубиваемого монстра будет меньше.
AVK>P.S. Не сочти за демагогию, ответ на твой вопрос уже содержится в моих постах.
Ну давай запретим рефлекшен... через него тоже можно натворить черт знает что.
А прикинь что будет если пустить соколов из соседней команды писать сервер приложений?
Короче давай завязывай с тем что Гашиш Кумар может напортачить. ИМХО это очень слабый аргумент. Ибо нормальный ПМ просто запретит ему писать макросы и все.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Короче давай завязывай с тем что Гашиш Кумар может напортачить. ИМХО это очень слабый аргумент. Ибо нормальный ПМ просто запретит ему писать макросы и все.
К томуже его можно посадить писать на томже C#. А вот пространство имен Parus.SmartClient.Controls.Win я бы предпочел писать на Nemerle.
Ведь интероп между Nemerle и C# абсолютно прозрачен.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
AVK>>Считаешь, что таки кое где бывает бесплатный сыр ака silver bullet? WH>Я так не считаю. Рано или позно найдется монстр которого этой пулей не убить. Но эта пуля легко убивает всех монстров которых убивает C# и еще кучу которых C# даже поцарапать не может.Вобщем лично я предпочту выходить на охоту на монстров с максимально мощными пулями ибо в этом случае вероятность нарваться на неубиваемого монстра будет меньше.
Но ведь С++/CLI, к примеру, почти во всем мощнее С#. С твоей философией надо бы его использовать.
AVK>>P.S. Не сочти за демагогию, ответ на твой вопрос уже содержится в моих постах. WH>Ну давай запретим рефлекшен... через него тоже можно натворить черт знает что.
А мы его со временем и запретим. При помощи CAS.
WH>Короче давай завязывай с тем что Гашиш Кумар может напортачить. ИМХО это очень слабый аргумент.
А я этот аргумент и не приводил. Если не веришь, можешь перечитать мои посты, например вот этот
Здравствуйте, AndrewVK, Вы писали:
AVK>Но ведь С++/CLI, к примеру, почти во всем мощнее С#. С твоей философией надо бы его использовать.
А немерле еще мощьнее если не надо писать неуправляемый код. К томуже если сравнивать C++/CLI и немерле то C++/CLI жуткий мутант... скрестили ежа с ужем и думают что это круто..., а немерле чистый язык без заморочек.
AVK>А я этот аргумент и не приводил. Если не веришь, можешь перечитать мои посты, например вот этот
. Loki, к примеру, совсем не твой Гашиш Кумар придумал.
Причем тут локи? Локи ужасен по тому что реализован на побочных эффекта шаблонов С++. В С++ в отличии от немерле метапрограммирование никто не планировал и именно по этому в С++ это выглядит так ужасно.
Судить о метапрограммирование по С++ это всеравно что судить об ООП по попытке реализовать его на brainfack'е.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Теперь возвращаясь к моему вопросу — очевидно, что язык программирования, помимо основной своей задачи, является еще и средством коммуникации разработчиков в команде. Даже в случае применения нестандартных техник лично я наблюдал проблемы понимания кода одних членов команды другими. Не думаю что кто то будет спорить, что возможностей по созданию непонимания у Nemerle существенно больше.
Больше. Но это "больше" не является той критической массой из-за которой метапрограммирование нужно запретить как вселенское зло. К тому же несколько макросов расширяющих синтаксис — это капля в море по сравненю с объёмом кода, который нужно будет постигнуть девелоперу только что пришёдшему на проект. Но вот эти самые макросы могут позволить существенно уменьшить код, с которым этому девелоперу придётся столкнуться. Так что всё зависит от того как на это посметреть.
AVK>Твоя точка зрения, как я понимаю, состоит в том, что разработчики достаточно благоразумны, чтобы использовать только те возможности, которые не создадут проблем, сопоставимых с гусем. Вот в это то я и не верю. Т.е. конечно разработчики не дебилы конечно, но процентов 90, если не меньше, не компетентны в вопросах дизайна ЯП. Опять же, я бы поверил что это не так, однако же ряд примеров, в том числе и ругаемый здесь С++, скорее убеждают меня в моей правоте, нежели наоборот.
Андрей, я тебе могу рассказать кучу примеров, когда те самые 90 процентов и без макросов делали такое, что у меня волосы начинали шевелиться во всех местах сразу. Про ужимание классов по 2к строк в 10 строчек я тебе не рассказывал? Если нет могу рассказать. Может ещё чего-нибудь вспомню. Но это всё не аргумент. С таким же успехом можно было бы 10 лет назад говорить, что ООП из-за порога вхождения несёт в себе только проблемы. Тем не менее сегодня это звучит смешно и ни один проект без ООП не обходится за исключением очень специальных случаев. Но вот общее увеличение сложности ПО ООП скомпенсировать удалось. Метапрограммирование — шаг в том же направлении. Не больше и не меньше.
И ещё вот что скажу. Пока у меня не было особенного выбора где-работать, куда пошлют туда и едем тушить пожар, то проблем с одноклеточными у меня было выше крыши. Толи их концентрация разваливает проекты, толи с самого начала неблагополучные проекты притягивают их массы Но последнее время у меня таких проблем гораздо меньше, т.к. приходится работать в небольших командах с классными инженерами, вполне вменяемыми и знающими. Не думаю, что у них будут какие-то большие проблемы с метапрограммированием.
AVK>Вопрос в соотношении. Как ни странно, но процент юзабельных библиотек Java существенно выше онных для C# или С++. И еще один момент, немаловажный при борьбе с такими орлами — рефакторинг. Алгоритм универсальный для макросов построить невозможно, следовательно как то надо придумывать обходные пути. А здесь я пока ничего хорошего в макросах не вижу.
Для C++ рефакторинга вообще пока не существует и народ как-то живёт. Да и рефакторингу как технологии без году неделя. Если тут есть серьёзные проблемы, то их надо решать, а не бегать от них.
AVK>Если говорить о прикладных DSL, то там крайне важен жесточайший контроль за прикладным кодом. В случае прикладных декларативных DSL мне понятны пути, как этого достичь. А в случае Nemerle?
Запретить создание и модификацию сборок с макросами инженерам, которым не положено это делать по должности.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Кто такой expression lambda и о каких оптимизациях речь? GZ>>Это те которые не statement. AVK>Опять непонятно. Плиз, открой спецификацию C# 3.0 и используй термины оттуда, иначе тебя сложно понимать. expression lambda, которые не statement, это, видимо, что то потрясающее, но мне не известное.
Занятно. Я тебе уже второй раз объясняю терминами взятыми из спецификации либо доков. Ты их читаешь?
Открываем, спеки от С#3.0, смотрим 23.6(собственно 26.3 Lambda expressions), замечаем что лямбда может быть двух типов, lambda c expression body, и lambda c statement body.
AVK>>>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость. GZ>>Не соглашусь. Во многом эта ситуация похожа на ситуацию с generic. Мы не знаем что это за тип, нас волнует только логика обработки. А ежели где напакостничили, то компилятор нам об этом сообщит. Или надо будет смотреть по коду что это за тип. AVK>О, последнее предложение ключевой момент.
И чем собственно они отличаются? Значит для генериков это простительно, а для type inference — это отстой?
Здравствуйте, VladD2, Вы писали:
GZ>>Насколько я правильно понял tuple, он при реализации в чистом виде подразумевают динамическую типизацию. VD>Кто тебе это сказал? Кортежи статически типизированны.
Sorry, прогнал. Можно и статически.
Здравствуйте, IT, Вы писали:
IT>Значит надо думать как подружить рефакторинг и макросы. В конце концов уже давно всем понятно, что язык без качественной IDE сегодня не представляет практически никакой коммерческой ценности. Проблема разработки API способного интегрировать языки в IDE уже давно назрела.
V>>Ну, отмазка, действительно, нелепая. В крайнем случае VB еще не отменили
IT>Она ещё более нелепа в свете того, что многие из нас начали свой путь с процедурного программирования. Т.е. ООП мы как-то смогли понять, что такое шаблоны как-то сообразили, на Windows перешли, COM, после 6 месяцев тумана в голове, тоже взяли, а вот DSL и метапрограммирование для нас это слишком сложно. Беспокоются они о нас Детский сад какой-то
просто поняли, что не смогут сделать, вот и всё. Слишком тяжел груз унаследованного кода, который тянет на дно.
Смотрел недавно API расширения студии — так это просто порнография какая-то. Даже не знаю, плакать или смеяться.
Здравствуйте, VladD2, Вы писали:
VD>Собственно я уже говорил, что рефакторинг упирается не в мифические роблемы динамичности, а в банальную проблему модификации кода. Если переменная или свойство создаются метакодом во время компиляции, то ее рефакторинг мягко говоря затруднен. Однако, метакод может и не порождать сушьностей. В этом случае он прекрасно будет рефакториться.
Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.
В конце концов, самый простой вариант — при выборе операции рефакторинга на любом сгенеренном коде делать навигацию на место в коде, где находится создавший его вызов макроса. А дальше юзер пусть сам думает.
Здравствуйте, Дарней, Вы писали:
Д>просто поняли, что не смогут сделать, вот и всё. Слишком тяжел груз унаследованного кода, который тянет на дно.
Так бы и сказали, а не спирали бы всё на ограниченность разработчиков. И, кстати, никто бы слова не сказал. Всем понятно, что задача разработки мэйнстрим платформы очень серьёзная и ответственная, без ошибок в ней не бывает.
Д>Смотрел недавно API расширения студии — так это просто порнография какая-то. Даже не знаю, плакать или смеяться.
Если смеяться, то только сквозь слёзы. Там по сути то что есть и API назвать трудно. Так... что получилось пока свои дизайнеры клепали.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, prVovik, Вы писали:
V>Просто сама идея автоматизированного рефакторинга не дружит с макросами и фокусами с АСТ, так как тут рафакторинг тулза помимо того, что должна уметь исполнять хитроумные и навороченные макросы (простые нам не нужны ), что само по себе не просто, но и заниматься реинжинирингом, что в общем случае сделать невозможно. То есть тут на карте либо автоматизированный рефакторинг, либо навороченные макросы. Выбрали, похоже, первое (имхо, правильно сделали). Все, конечно, ИМХО.
Лучшеб выбрали макросы, а если сами не могут придумать как их отрефакторить, то найдутся те, кто сможет. Возможно, JetBrains, а возможно кто еще. Да и кто вам сказал, что действительно выбор между двух "либо". Почему не оставить автоматизированный рефакторинг в том виде в каком он есть сейчас, а для макросов его просто не добавлять.
И вообще, помимо возможностей описания макросов, можно добавить возможности декларативного описания действий этих макросов для средств рефакторинга.
Здравствуйте, ie, Вы писали:
ie>Лучшеб выбрали макросы, а если сами не могут придумать как их отрефакторить, то найдутся те, кто сможет. Возможно, JetBrains, а возможно кто еще. Да и кто вам сказал, что действительно выбор между двух "либо". Почему не оставить автоматизированный рефакторинг в том виде в каком он есть сейчас, а для макросов его просто не добавлять. ie>И вообще, помимо возможностей описания макросов, можно добавить возможности декларативного описания действий этих макросов для средств рефакторинга.
дык сначала наверное надо придумать как это все провернуть, а потом делать. А то получится как обычно, понапихают фич, потом через годик репу почешут, и поймут, что все надо было делать не так, а потому ждите C#15, который несовместим с предыдущими версиями (несовместим — это в лучшем случае. В худшем будет C# => С++ )
Здравствуйте, IT, Вы писали:
IT>Больше. Но это "больше" не является той критической массой из-за которой метапрограммирование нужно запретить как вселенское зло.
А вот это уже фик его знает. Пока не будет наработана база реальных решений вряд ли кто точно сможет на это ответить. Когда речь идет о экспериментальных языках, я обеими руками за. Я сам тут, на rsdn, чуть ли не самый первый ратовал за кодогенерацию, в том числе и совмещенную с рукописными исходниками. Но когда тут говорят, что нужно выкинуть C# и срочно переходить на Nemerle, то я, мягко говоря, подобный экстремизм не приемлю. Потому как, даже если идея в целом правильная, понадобится пройтись по тачке грабель, прежде чем из нее получится что то путное. Вспомни, к примеру, Java — какой это по началу был уродец, при том что идея управляемой платформы у тебя сейчас вроде как отторжения не вызывает.
IT> К тому же несколько макросов расширяющих синтаксис — это капля в море по сравненю с объёмом кода, который нужно будет постигнуть девелоперу только что пришёдшему на проект. Но вот эти самые макросы могут позволить существенно уменьшить код, с которым этому девелоперу придётся столкнуться. Так что всё зависит от того как на это посметреть.
Опять же — совершенно неизвестно куда эта дорожка может завести. Страуструп с шаблонами тоже наверное не думал, что их кто то для генерации кода использовать будет.
IT>Андрей, я тебе могу рассказать кучу примеров, когда те самые 90 процентов и без макросов делали такое, что у меня волосы начинали шевелиться во всех местах сразу.
Я сам таких примеров понарассказать могу вагон. И у меня сейчас закрадывается мысль отказаться от C# в качестве языка для прикладного кода из-за того что он слишком много позволяет, а тут Nemerle предлагается .
IT>Метапрограммирование — шаг в том же направлении. Не больше и не меньше.
Шаг то он однозначно. А вот насчет направления я не уверен. Тут как с болотом — пока не шагнешь, не ощутишь в какое дерьмо вляпался. Я конечно верю, что некоторые, с особым обонянием, способны ощутить запах вышеозначенной субстанции на расстоянии, не взирая на покрывающую его болотную жижу, но рядом всегда есть толпа других, которые реально ничего не чувствуют, а только делают вид. А уж если меня начинают убеждать, что куда не плюнь, везде розами благоухает (это на болоте то!), то я совсем в смущение вхожу, потому как с детства помню, чем закончился ботанический эксперимент товарища Буратины (ровно как и общение его с болотом).
IT>Для C++ рефакторинга вообще пока не существует и народ как-то живёт.
(Слово на букву Х) живет он, однако. Я так не хочу.
IT> Да и рефакторингу как технологии без году неделя. Если тут есть серьёзные проблемы, то их надо решать, а не бегать от них.
Надо, кто же спорит. Только ведь у группы LINQ немножко другая задача. Им надо к концу года выкатить рабочий инструмент. А научными проблемами уже MSR занимается.
AVK>>Если говорить о прикладных DSL, то там крайне важен жесточайший контроль за прикладным кодом. В случае прикладных декларативных DSL мне понятны пути, как этого достичь. А в случае Nemerle?
IT>Запретить создание и модификацию сборок с макросами инженерам, которым не положено это делать по должности.
И регулярно code review делать?
Вобщем, в кратце, если мы имеем потенциальные проблемы, то должны быть средства их решения. Административные приемы это нифига не средства, это только временное решение. Нужны жесткие, автоматически проверяемые политики, позволяющие удерживать орлов в обозначенном коридоре. Но про подобное я пока не слышал ни от создателей Nemerle, ни от здешних агитаторов.
Здравствуйте, GlebZ, Вы писали:
AVK>>Опять непонятно. Плиз, открой спецификацию C# 3.0 и используй термины оттуда, иначе тебя сложно понимать. expression lambda, которые не statement, это, видимо, что то потрясающее, но мне не известное. GZ>Занятно. Я тебе уже второй раз объясняю терминами взятыми из спецификации либо доков. Ты их читаешь?
GZ>Открываем, спеки от С#3.0, смотрим 23.6(собственно 26.3 Lambda expressions),
Не находишь, что Lambda expression и Expression lambda, это, мягко говоря, не одно и то же? Первое обычно здесь называют просто lambda, а второе это бессмыслица.
GZ> замечаем что лямбда может быть двух типов, lambda c expression body, и lambda c statement body.
Вот теперь понятно. Впредь буду признателен, если и в дальнейшем ты воздержишься от изобретения терминов.
AVK>>О, последнее предложение ключевой момент. GZ>И чем собственно они отличаются? Значит для генериков это простительно, а для type inference — это отстой?
Для генериков это происходит по очень примитивному алгоритму, который несложно предсказать, а вот в Nemerle логика может быть весьма непростой для быстрого понимания.
Здравствуйте, AndrewVK, Вы писали:
AVK>А вот это уже фик его знает. Пока не будет наработана база реальных решений вряд ли кто точно сможет на это ответить.
При наличии таких решений, их скорее введут в шарп целиком, как элементы языка.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>О, последнее предложение ключевой момент. GZ>>И чем собственно они отличаются? Значит для генериков это простительно, а для type inference — это отстой? AVK>Для генериков это происходит по очень примитивному алгоритму, который несложно предсказать, а вот в Nemerle логика может быть весьма непростой для быстрого понимания.
type inference к макросам Nemerle отношения не имеют.
Здравствуйте, Дарней, Вы писали:
Д>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.
Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно. А вот как можно рефакторить код, которого не существует (код сгенерённый макросами) я не понимаю.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
GZ>>type inference к макросам Nemerle отношения не имеют. AVK>А я где то писал что имеют?
Ну судя по тому, что я Nemerle вообще не упоминал, ты с разговора на разговор не переключился. Мы обсуждали твое мнение что type reference существенно ухудшают читабельность.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну судя по тому, что я Nemerle вообще не упоминал, ты с разговора на разговор не переключился. Мы обсуждали твое мнение что type reference существенно ухудшают читабельность.
type inference?
Цитирую:
AVK>>>и type inference
GZ>>Тоже Влад тут уже возмущался. Недоделанный какой-то.
Ссылка на возмущения Влада для пояснения откуда взялся Nemerle нужна?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно.
Рефакторить то можно, трудно сделать так, чтобы отрефакторенный код после рефакторинга не потерял работоспособность. Тут нужны специальные "обрезанные" макросы, которые не могут ничего знать об объектах (типах, методах и пр.), с которыми они будут работать, эти макросы должны быть в некоторой степени контекстно независимыми. Проблема в том, что на таких "обрезанных" макросах нельзя будет реализовать даже такю простейшую с точки зрения метопрограммирования вещь, как параметрические типы (шаблоны классов в "классическом" понимании, дженерики (если забыть про их компонентность)). Может быть, я ошибаюсь, хз.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ссылка на возмущения Влада для пояснения откуда взялся Nemerle нужна?
Нет не нужна. Я ее помню. Там было достаточно много рекламы Nemerle, и мало того, что и другие языки прекрасно поддерживают вывод типов.
А это что?
AVK>>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость.
GZ>Не соглашусь. Во многом эта ситуация похожа на ситуацию с generic. Мы не знаем что это за тип, нас волнует только логика обработки. А ежели где напакостничили, то компилятор нам об этом сообщит. Или надо будет смотреть по коду что это за тип.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Дарней, Вы писали:
Д>>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.
ANS>Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно. А вот как можно рефакторить код, которого не существует (код сгенерённый макросами) я не понимаю.
Ну или, как тут уже упоминал Влад, порождающие макросы. Представь: макрос порождает класс, который затем "ручками" используется в коде. Мы пытаемся поменять, например, имя какого-нибудь метода. Получаем две проблемы:
1) Не главная проблема. Рефакторинг тулза не может знать, что надо подкрутить в макросе, чтобы все заработало. Она вообще не будет знать, что существует некий макрос, который потом, т.е. после работы рефактор тулзы сгенерирует соответствующий класс. Как побочный эффект, во всех местах, где будет использоваться этот класс, мы увидели бы от решарпера "красные полоски", сообщающие о синтаксической ошибке. Но это не главное. В одном месте не обломится и ручками поправить.
2) Главная проблема. Рефакторинг тулза не будет знать, что все случаи использования методов класса принадлежат, на самом деле, одному классу. То есть если метод "А" генерируемого класса использовался в программе 300 раз, то после изменения его сигнатуры в макросе, нам ручками предстоит поменять вызов этого метода в программе в 300 местах. А теперь представь, что получится, если придется рефакторить крупную систему, которую писали "кул хацкеры". Проще ее будет заново переписать, чем рефакторить
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
V>>Неужели, в немерле есть отладчик времени компиляции?
VD>Ага! И еще какая!!! Код макросов — это код на Немерле. И этим все сказано! Так что все приемы программирования и отладки идентичны как в метакоде, так и в обычном коде.
С той лишь разницей, что для того, чтобы пойматься на брекпоинте в теле макроса, надо как-то приаттачиваться к процессу компилятора "на лету"
Реализуемо, но реализовано пока
Здравствуйте, prVovik, Вы писали:
Д>>>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.
ANS>>Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно. А вот как можно рефакторить код, которого не существует (код сгенерённый макросами) я не понимаю. V>Ну или, как тут уже упоминал Влад, порождающие макросы. Представь: макрос порождает класс, который затем "ручками" используется в коде. Мы пытаемся поменять, например, имя какого-нибудь метода. Получаем две проблемы:
А, понятно понятно. Значит нужно запускать компиляцию после рефакторинга и запрещать оный если есть оно не компилицца.
И вообще, чем лично меня привлекает шарп в первую очередь, это то, что благодаря рефакторингу я могу очень быстро и безопасно "нагинать" программу в такую позу, которая мне нужна. За считанные минуты можно провести очень серьезные и масштабные преобразования программы и адаптировать ее к изменившемся требованиям, либо представлениям о правильном способе решения задачи. Только не надо рассказывать, что при хорошей системе макросов, программа не нуждается в рефакторинге, а рефакторинг-тулза, это костыли, которые спасают от отсутствия макросов
Здравствуйте, AndrewVK, Вы писали:
IT>>Больше. Но это "больше" не является той критической массой из-за которой метапрограммирование нужно запретить как вселенское зло.
AVK>А вот это уже фик его знает. Пока не будет наработана база реальных решений вряд ли кто точно сможет на это ответить.
Реальные решения я тебе несколькими постами ранее продемонстрировал на самой наитипичнейшей задаче. В дополнение могу сказать, что макросы применимы практически везде, где просматриваются паттерны и происходит набор однообразного кода, который невозможно зареюзать штатными средствами. Мест таких в любой задаче можно найти мильён.
AVK>Потому как, даже если идея в целом правильная, понадобится пройтись по тачке грабель, прежде чем из нее получится что то путное.
Как раз по граблям мы сегодня каждый день ходим, причём без шансов от них избавиться. Я тут недавно опять параметр забыл забоксить, три часа убил на поиски
AVK>Вспомни, к примеру, Java — какой это по началу был уродец, при том что идея управляемой платформы у тебя сейчас вроде как отторжения не вызывает.
Я не помню какой была Java. Помню только что религия и высокомерие плюсовика мне тогда не позволяли так низко пасть
AVK>Опять же — совершенно неизвестно куда эта дорожка может завести. Страуструп с шаблонами тоже наверное не думал, что их кто то для генерации кода использовать будет.
Проблема с шаблонами в их совершенной нечитабельности, громоздкости и невозможности по человечески что-либо отладить. Первого прикосновения к Немерле достаточно, чтобы понять, что в нём таких проблем нет.
AVK>Я сам таких примеров понарассказать могу вагон. И у меня сейчас закрадывается мысль отказаться от C# в качестве языка для прикладного кода из-за того что он слишком много позволяет, а тут Nemerle предлагается .
Мда... как всё запущено...
AVK>Шаг то он однозначно. А вот насчет направления я не уверен. Тут как с болотом — пока не шагнешь, не ощутишь в какое дерьмо вляпался.
Ну не надо нам тут таких страшилок в качестве аналогий приводить. Всё в Немерле нормально. Нигде там ничего не воняет. Очень красивый и выразительный язык. Даже функциональщину ребятам удалось сделать с человеческим лицом. Тому же C# до него со своими потугами в виде анонимных делегатов ещё как раком (простите мне мой французский) до Парижа.
AVK> Я конечно верю, что некоторые, с особым обонянием, способны ощутить запах вышеозначенной субстанции на расстоянии, не взирая на покрывающую его болотную жижу, но рядом всегда есть толпа других, которые реально ничего не чувствуют, а только делают вид. А уж если меня начинают убеждать, что куда не плюнь, везде розами благоухает (это на болоте то!), то я совсем в смущение вхожу, потому как с детства помню, чем закончился ботанический эксперимент товарища Буратины (ровно как и общение его с болотом).
Ты в детстве слишком много неправильных книжек читал. Буратина же был банальным воришкой. Ты ещё наверное и самый садистский мультик "Ну, погоди!" смотрел?
IT>>Для C++ рефакторинга вообще пока не существует и народ как-то живёт.
AVK>(Слово на букву Х) живет он, однако. Я так не хочу.
И я не хочу так как сейчас живу. Хочу забыть об эмите как о страшном сне.
IT>> Да и рефакторингу как технологии без году неделя. Если тут есть серьёзные проблемы, то их надо решать, а не бегать от них.
AVK>Надо, кто же спорит. Только ведь у группы LINQ немножко другая задача. Им надо к концу года выкатить рабочий инструмент. А научными проблемами уже MSR занимается.
Да причём тут LINQ? Речь о том, что MS совсем отмахивается от возможности привнести в язык метапрограммирование. Вот это озадачивает.
AVK>Нужны жесткие, автоматически проверяемые политики, позволяющие удерживать орлов в обозначенном коридоре. Но про подобное я пока не слышал ни от создателей Nemerle, ни от здешних агитаторов.
MS, по-моему, что-то пыталась сделать в предыдущих студиях с помощью ентерпрайз шаблонов. Как эксперимент? Провалился?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Реальные решения я тебе несколькими постами ранее продемонстрировал на самой наитипичнейшей задаче.
Реальные решения, это когда реальная команда не из одного человека создаст и будет поддерживать реальный продукт для реального заказчика. А концептом я и сам могу много напридумывать, только концепты, они на то и концепты, что кроме концепции на них ничего больше не видно. А меня интересуют побочные эффекты.
AVK>>Вспомни, к примеру, Java — какой это по началу был уродец, при том что идея управляемой платформы у тебя сейчас вроде как отторжения не вызывает.
IT>Я не помню какой была Java.
Зато я помню. Не приведи господь
IT>Проблема с шаблонами в их совершенной нечитабельности, громоздкости и невозможности по человечески что-либо отладить. Первого прикосновения к Немерле достаточно, чтобы понять, что в нём таких проблем нет.
Зато наверняка есть другие.
IT>Ну не надо нам тут таких страшилок в качестве аналогий приводить.
Это не аналогии, это образные выражения.
AVK>>Надо, кто же спорит. Только ведь у группы LINQ немножко другая задача. Им надо к концу года выкатить рабочий инструмент. А научными проблемами уже MSR занимается.
IT>Да причём тут LINQ?
На заголовок топика посмотри, да?
IT> Речь о том, что MS совсем отмахивается от возможности привнести в язык метапрограммирование. Вот это озадачивает.
Совсем отмахивается в промышленном языке. При этом спонсирует тот самый Nemerle.
IT>MS, по-моему, что-то пыталась сделать в предыдущих студиях с помощью ентерпрайз шаблонов.
Не то. Они на уровне среды это делали, а надо на уровне языка.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>Собственно я уже говорил, что рефакторинг упирается не в мифические роблемы динамичности, а в банальную проблему модификации кода. Если переменная или свойство создаются метакодом во время компиляции, то ее рефакторинг мягко говоря затруднен. Однако, метакод может и не порождать сушьностей. В этом случае он прекрасно будет рефакториться.
Д>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.
Простой пример. Макрос Accesor порождающий свойство по полю. Предположим, что мы хотим изменить имя своайства. Что для этого должен сделать рефакторер?
Д>В конце концов, самый простой вариант — при выборе операции рефакторинга на любом сгенеренном коде делать навигацию на место в коде, где находится создавший его вызов макроса.
Нет четкой корелляции между макросом и кодом им порожденным. Этот код потенциально может быть вообще новым классом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>2) Главная проблема. Рефакторинг тулза не будет знать, что все случаи использования методов класса принадлежат, на самом деле, одному классу. То есть если метод "А" генерируемого класса использовался в программе 300 раз, то после изменения его сигнатуры в макросе, нам ручками предстоит поменять вызов этого метода в программе в 300 местах. А теперь представь, что получится, если придется рефакторить крупную систему, которую писали "кул хацкеры". Проще ее будет заново переписать, чем рефакторить
Это он знать может. Но первая проблема остается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А, понятно понятно. Значит нужно запускать компиляцию после рефакторинга и запрещать оный если есть оно не компилицца.
Хм. Простая но гениальная мысль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
V>И вообще, чем лично меня привлекает шарп в первую очередь, это то, что благодаря рефакторингу я могу очень быстро и безопасно "нагинать" программу в такую позу, которая мне нужна.
Во втором шарпе я сталкиваюсь с отказом рефакторить код очень часто. Особенно с итераторами и анонимными методами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, noetic, Вы писали:
N>С той лишь разницей, что для того, чтобы пойматься на брекпоинте в теле макроса, надо как-то приаттачиваться к процессу компилятора "на лету" N>Реализуемо, но реализовано пока
Елы, палы. Еще один. Зачем к нему атачиться на лету? Поставь в качестве хост-процесса в отладчике сам ncc.exe и ставь точки останова в любых используемых макросах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Чуть ниже. Когда я говорил что определенный сухой остаток есть, я перечислял технологии, которые, по моему мнению, являются вполне полезными и вне DLINQ сотоварищи. Анонимные тьипы в этот перечень не входили.
И что? От этого они стали доработанными?
Я просто согласился с GlebZ в том, что МС в C# 3.0 выдает ряд явно недоработанных фич. Что очень вредно для дальнейшего развития языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>А, ну понеслась. Спорьте, мужчина, без меня. (и этот человек обвиняет меня в переходе на личности )
Ты даже не замечашь, что постоянно этим грешишь. За то в других ой как любишь это же поискать.
Я то хотя бы понимаю, что мало от тебя чем отличаюсь.
AVK>Анализ. В рамках устного общения в режиме цейтнота времени? Ты видимо чего то не понимаешь — описываемый разговор происходил в рамках доклада по C# 3.0 и я и так отнял минут 10 от часового доклада на свои вопросы.
Я так понял, что у вас было личное общение в непринужденной форме. Если это были вопросы с места, то все ясно. Тут конечно особо не по спрашивашь.
AVK>Только вот этот вопрос легко допускает непринужденный уход от ответа, потому что он сильно неконкретен.
Еще раз. Меня устроил бы лбой ответ. Особенно если человека можно подергать во свободное время.
То что тебе что-то не интересно еще не значит, что не стоит задавать вопрос. Ведь может оказаться интересно дургим. А ты ведь на то и МВП, чтобы помогать другим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Вобщем лично я предпочту выходить на охоту на монстров с максимально мощными пулями ибо в этом случае вероятность нарваться на неубиваемого монстра будет меньше.
Точно. BFG с неограниченными патронами лучше любой серебрянной пули.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Твоя точка зрения, как я понимаю, состоит в том, что разработчики достаточно благоразумны, чтобы использовать только те возможности, которые не создадут проблем, сопоставимых с гусем. Вот в это то я и не верю. Т.е. конечно разработчики не дебилы конечно, но процентов 90, если не меньше, не компетентны в вопросах дизайна ЯП. Опять же, я бы поверил что это не так, однако же ряд примеров, в том числе и ругаемый здесь С++, скорее убеждают меня в моей правоте, нежели наоборот.
И что по-твоему индусокодерам лучше двавать в руки перенавороченный C# 3.0 и эмулировать прикладную логику классами и другими плохо подходящими вещами. Или все же заставить пару опытных программистов написать простенький ДСЛ-чик для решения прикладнухи и объяснить индокодерам как его исползовать?
Мне кажется второе явно разумнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
AVK>>Считаешь, что таки кое где бывает бесплатный сыр ака silver bullet? WH>Я так не считаю. Рано или позно найдется монстр которого этой пулей не убить. Но эта пуля легко убивает всех монстров которых убивает C# и еще кучу которых C# даже поцарапать не может. WH>Вобщем лично я предпочту выходить на охоту на монстров с максимально мощными пулями ибо в этом случае вероятность нарваться на неубиваемого монстра будет меньше.
Да, но и своих немало замочит. Проблема в том, что слишком много стен, и слишком много народу которые оружием пользоваться не умеют. Палят из наганов, налево и направо. Иногда по монстрам, иногда просто так, потому как пуляться прикалывает. Как результат, высокие потери среди личного состава от рикошетов. Монстра может и не замочит, зато в своих точно попадет. И не знаешь что лучше. Программирование коммандная игра, у нее должна быть единая и эффективная тактика. Правила хорошего дизайна надо выполнять, а тут оказывается, что и немногие эти правила знают. Вот и палят без правил.
А тут ты предлагаешь возвести новые стенки. Монстры те же самые, к ним привыкли, уже как родные, знаешь где водопой, где гнездо. Может коридор и короче, и оружие помощнее, только пока шишек не набьешь, да пару раз не грохнешь под ноги из RPG, хрен узнаешь что лучше.
Вобщем, я согласен с Андреем. Пока не будет хорошей методики построения программ, пока не будет реальных проектов, все это неприменимо и представляет только научный интерес.
Здравствуйте, VladD2, Вы писали:
AVK>>А, ну понеслась. Спорьте, мужчина, без меня. (и этот человек обвиняет меня в переходе на личности )
VD>Ты даже не замечашь, что постоянно этим грешишь. За то в других ой как любишь это же поискать. VD>Я то хотя бы понимаю, что мало от тебя чем отличаюсь.
Брейк господа модераторы. Оба хороши.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
хъ
GZ>Вобщем, я согласен с Андреем. Пока не будет хорошей методики построения программ, пока не будет реальных проектов, все это неприменимо и представляет только научный интерес.
Доказательства по аналогии...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
IT>>Реальные решения я тебе несколькими постами ранее продемонстрировал на самой наитипичнейшей задаче.
AVK>Реальные решения, это когда реальная команда не из одного человека создаст и будет поддерживать реальный продукт для реального заказчика. А концептом я и сам могу много напридумывать, только концепты, они на то и концепты, что кроме концепции на них ничего больше не видно. А меня интересуют побочные эффекты.
Постить на RSDN концепты у меня нет привычки. Всё это реально опробовано и реально работает в реальных проектах. На RSDN это появляется только когда руки доходят, чтобы оформить это хозяйство в надлежащем для использования другими виде. Так что тут ты мимо кассы.
IT>>Проблема с шаблонами в их совершенной нечитабельности, громоздкости и невозможности по человечески что-либо отладить. Первого прикосновения к Немерле достаточно, чтобы понять, что в нём таких проблем нет.
AVK>Зато наверняка есть другие.
Пока за пару месяцев баталий никто не смог найти ничего серьёзного
IT>>Ну не надо нам тут таких страшилок в качестве аналогий приводить. AVK>Это не аналогии, это образные выражения.
Ну не надо нам тут таких страшилок в качестве образных выражений приводить.
IT>>Да причём тут LINQ? AVK>На заголовок топика посмотри, да?
И где там LINQ
IT>> Речь о том, что MS совсем отмахивается от возможности привнести в язык метапрограммирование. Вот это озадачивает.
AVK>Совсем отмахивается в промышленном языке. При этом спонсирует тот самый Nemerle.
Вот и пусть спонсируют. А отмахиваются зря. Сдаётся мне, что .NET как многоязыковая среда не потерпит поражений. Как только появится достойная альтернатива C# его подвинут быстро и далеко. И никакие рюшечки в виде LINQ не помогут. В общем, не дальновидно это.
IT>>MS, по-моему, что-то пыталась сделать в предыдущих студиях с помощью ентерпрайз шаблонов. AVK>Не то. Они на уровне среды это делали, а надо на уровне языка.
Это как раз можно было бы сделать на Немерле. Выдал в зубы ограниченный синтаксис с проверками шаг в лево, шаг в право в компайл-тайме и пилите, Шура, она золотая.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Простой пример. Макрос Accesor порождающий свойство по полю. Предположим, что мы хотим изменить имя своайства. Что для этого должен сделать рефакторер?
Допустим, мы стоим на месте в коде, где используется это свойство. Кликаем на него, рефакторер прыгает на место в коде, где определено это поле. А юзер пусть сам разбирается, что с этим макросом делать. Это — самый простой вариант.
Можно конечно придумать варианты посложнее — например, чтобы каждый макрос сообщал IDE о доступных для него операциях рефакторинга. Но овчинка не стоит выделки, ИМХО.
VD>Нет четкой корелляции между макросом и кодом им порожденным. Этот код потенциально может быть вообще новым классом.
А по хорошему, должна быть. IDE нужно иметь точную информацию, "кто кого породил" , чтобы рефакторинг мог нормально работать.
Здравствуйте, GlebZ, Вы писали:
GZ>Да, но и своих немало замочит. Проблема в том, что слишком много стен, и слишком много народу которые оружием пользоваться не умеют. Палят из наганов, налево и направо.
неопытным солдатам оружия в руки вообще не дают. Только молоток, чтобы добивать упавших монстров
А тех, кто раздает BFG кому попало — под военный трибунал
Здравствуйте, IT, Вы писали: IT>Андрей, это произошло! И то что вы там все стояли и смиренно в знак согласия махали головами только подтверждает этот факт. Как можно решать за пользователей что им нужно? У меня просто слов нет
А у меня есть. Я думаю, что просто мы тут, как декабристы — страшно далеки от народа. А МС наверняка вбухали тонны бабла в опросы пользователей. И именно пользователи решили, что нужно, а что — нет. Ты всего лишь пробился в первые ряды. Посмотришь налево — одни гении стоят, направо — та же ерунда. А ты назад обернись — там еще целый стадион людей, которым со стола-то вытереть доверить страшно. И для них риск напороть ерунду как раз перевешивает преимущества продвинутой модели.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А у меня есть. Я думаю, что просто мы тут, как декабристы — страшно далеки от народа. А МС наверняка вбухали тонны бабла в опросы пользователей. И именно пользователи решили, что нужно, а что — нет. Ты всего лишь пробился в первые ряды. Посмотришь налево — одни гении стоят, направо — та же ерунда. А ты назад обернись — там еще целый стадион людей, которым со стола-то вытереть доверить страшно. И для них риск напороть ерунду как раз перевешивает преимущества продвинутой модели.
подозреваю, что эти деньги просто бездарно пускаются на ветер. По иному я не могу объяснить тот факт, что диалог открытия файлов только недавно сделали с изменяемым размером. Проблему, когда фоновое приложение вдруг разворачивается и становится активным, до сих пор толком не решили. Особенно это радует, когда ты набираешь текст в одном окне, а другое окно его подменяет. И таких ляпов — тонны.
Здравствуйте, IT, Вы писали:
IT>Постить на RSDN концепты у меня нет привычки. Всё это реально опробовано и реально работает в реальных проектах. На RSDN это появляется только когда руки доходят, чтобы оформить это хозяйство в надлежащем для использования другими виде. Так что тут ты мимо кассы.
Я не про то, что у тебя сейчас есть, а про тот бенефит, который ты надеешься получить от макросов.
AVK>>Зато наверняка есть другие.
IT>Пока за пару месяцев баталий никто не смог найти ничего серьёзного
А их вобще искали? Сдается мне что нет. И баталии это не показатель — показатель см. выше
IT>>>Да причём тут LINQ? AVK>>На заголовок топика посмотри, да?
IT>И где там LINQ
Разговор был о нем.
IT>Это как раз можно было бы сделать на Немерле. Выдал в зубы ограниченный синтаксис с проверками шаг в лево, шаг в право в компайл-тайме и пилите, Шура, она золотая.
А как в Nemerle эти проверки добавить? Чтобы не новый AST генерить, а контроллировать существующий?
Здравствуйте, VladD2, Вы писали:
AVK>>Чуть ниже. Когда я говорил что определенный сухой остаток есть, я перечислял технологии, которые, по моему мнению, являются вполне полезными и вне DLINQ сотоварищи. Анонимные тьипы в этот перечень не входили.
VD>И что? От этого они стали доработанными?
А то, что мои слова, с которыми ты споришь, к анонимным типам не относились.
Здравствуйте, VladD2, Вы писали:
AVK>>А, ну понеслась. Спорьте, мужчина, без меня. (и этот человек обвиняет меня в переходе на личности )
VD>Ты даже не замечашь, что постоянно этим грешишь. За то в других ой как любишь это же поискать. VD>Я то хотя бы понимаю, что мало от тебя чем отличаюсь.
Я уж как нибудь разберусь, тем более что я никого в переходе на личности не обвиняю. Ты лучше за собой последи.
AVK>>Анализ. В рамках устного общения в режиме цейтнота времени? Ты видимо чего то не понимаешь — описываемый разговор происходил в рамках доклада по C# 3.0 и я и так отнял минут 10 от часового доклада на свои вопросы.
VD>Я так понял, что у вас было личное общение в непринужденной форме. Если это были вопросы с места, то все ясно. Тут конечно особо не по спрашивашь.
Именно. В непринужденной форме за пивом мы общались с Клеменсом, но это никого не заинтересовало.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я не про то, что у тебя сейчас есть, а про тот бенефит, который ты надеешься получить от макросов.
А... понятно. Я понял, если ты лично не видишь бенефитов, то их как бы и нет
IT>>Пока за пару месяцев баталий никто не смог найти ничего серьёзного
AVK>А их вобще искали? Сдается мне что нет. И баталии это не показатель — показатель см. выше
Были бы серьёзные изъяны — нашли бы без сомнения. Вон Скалу в соседнем топике уже пинают вовсю
IT>>И где там LINQ
AVK>Разговор был о нем.
Разговор был о том, что MS сама принимает решения что нам можно, а до чего мы ещё не доросли.
IT>>Это как раз можно было бы сделать на Немерле. Выдал в зубы ограниченный синтаксис с проверками шаг в лево, шаг в право в компайл-тайме и пилите, Шура, она золотая.
AVK>А как в Nemerle эти проверки добавить? Чтобы не новый AST генерить, а контроллировать существующий?
Надо разбираться. Опять же, что именно ты хочешь запрещать?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
AVK>>А их вобще искали? Сдается мне что нет. И баталии это не показатель — показатель см. выше
IT>Были бы серьёзные изъяны — нашли бы без сомнения. Вон Скалу в соседнем топике уже пинают вовсю
Здравствуйте, Sinclair, Вы писали:
S>А у меня есть. Я думаю, что просто мы тут, как декабристы — страшно далеки от народа. А МС наверняка вбухали тонны бабла в опросы пользователей.
Т.е. они с самого начала хотели, практически всё сделали, а потом решили, что лучше ещё с десяток лет подождать? Так что ли? А пока осчастливить человечество LINQ. Правда, при этом придётся некоторые секретные фичи раскрыть, но мы их сделаем совсем калеками, чтобы ни ни. Ну не бред ли
Я думаю, что MS элементарно не может это сделать, но делает грозный вид и прикрывается подобными легендами. Дарней прав. При ближайшем рассмотрении у новых продуктов MS столько недоделок, косяков в дизайне и порой просто глюков, что диву даёшься.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Курилка, Вы писали:
IT>>Были бы серьёзные изъяны — нашли бы без сомнения. Вон Скалу в соседнем топике уже пинают вовсю
К>Если не сложно можно ссылку?
Здравствуйте, IT, Вы писали:
AVK>>Я не про то, что у тебя сейчас есть, а про тот бенефит, который ты надеешься получить от макросов.
IT>А... понятно. Я понял, если ты лично не видишь бенефитов, то их как бы и нет
Бенефиты вижу, не вижу подводные камни (или полное их отсутствие) под этими бенефитами.
AVK>>А их вобще искали? Сдается мне что нет. И баталии это не показатель — показатель см. выше
IT>Были бы серьёзные изъяны — нашли бы без сомнения.
Сомневаюсь. Иначе бы все языки, на выпуск которых потраченно n-ное количество усилий были бы практически без недостатков. Наличие ошибок в дизайне практически всех языков это непреложный факт.
AVK>>А как в Nemerle эти проверки добавить? Чтобы не новый AST генерить, а контроллировать существующий?
IT>Надо разбираться. Опять же, что именно ты хочешь запрещать?
Использование неразрешенных макросов, использование определенных синтаксических конструкций. Да много чего, так сразу и не перечислишь.
Здравствуйте, AndrewVK, Вы писали:
IT>>А... понятно. Я понял, если ты лично не видишь бенефитов, то их как бы и нет
AVK>Бенефиты вижу, не вижу подводные камни (или полное их отсутствие) под этими бенефитами.
Т.е. ты хочешь сказать, что если бы мы знали 15 лет назад, что в C++ полно недостатков, то сейчас бы на нём никто не писал? Это же эволюция, а ты хочешь построить сразу коммунизм
AVK>Сомневаюсь. Иначе бы все языки, на выпуск которых потраченно n-ное количество усилий были бы практически без недостатков. Наличие ошибок в дизайне практически всех языков это непреложный факт.
Ok, появятся недостатки, появится новый язык без недостатков. Свято место пусто не бывает.
AVK>>>А как в Nemerle эти проверки добавить? Чтобы не новый AST генерить, а контроллировать существующий?
IT>>Надо разбираться. Опять же, что именно ты хочешь запрещать?
AVK>Использование неразрешенных макросов, использование определенных синтаксических конструкций. Да много чего, так сразу и не перечислишь.
Может есть какие-нибудь атрибуты-макросы уровня сборки? Если нет, то думаю можно описать проблему и рассказать о ней создателям языка.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Т.е. ты хочешь сказать, что если бы мы знали 15 лет назад, что в C++ полно недостатков, то сейчас бы на нём никто не писал? Это же эволюция, а ты хочешь построить сразу коммунизм
Я ничего не имею против эволюции. Я против того чтобы начинать вносить в промышленный язык совсем необкатанные технологии.
AVK>>Использование неразрешенных макросов, использование определенных синтаксических конструкций. Да много чего, так сразу и не перечислишь.
IT>Может есть какие-нибудь атрибуты-макросы уровня сборки? Если нет, то думаю можно описать проблему и рассказать о ней создателям языка.
На это надо время. А мне и так хочется сделать много всего интересного, да еще и деньги зарабатывать нужно.
Здравствуйте, AndrewVK, Вы писали:
AVK>А их вобще искали? Сдается мне что нет. И баталии это не показатель — показатель см. выше
Я постоянно пытаюсь это сделать. Пока что основными недостатками являются недоработки, клюки и не всегда понятные сообщения компилятора. Причем разработчики языка быстро откликаются и исправляют найденные недочеты.
Более того проект под БСД-шной лиценией и можно создавать его клоны на любых условиях (лишь бы авторов упомянуть). Так что думаю ошибки в скором времени перестанут досождать.
Из идеологических проблем пожалуй досождает только отложенность типизации макросов. Для их отладки имеет смысл применять юнит тесты. Но все же это не те проблемы.
Еще можно назвать в качестве проблемы отсуствие мощьной библиотеки метапрограммирования. Ну, и разбросанность информации о языке и макросах. На сайте есть почти все, да и есши что можно быстро спросить, но вот полноценного хэлпа нет.
Думаю, что все это всего лишь проблемы роста.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я ничего не имею против эволюции. Я против того чтобы начинать вносить в промышленный язык совсем необкатанные технологии.
Ага. 30 лет — это не срок для обкатки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>И что по-твоему индусокодерам лучше двавать в руки перенавороченный C# 3.0
AVK>А в нем есть опасные конструкции?
Тут нужно определить, что ты считашь опасными консрукциями (для начала). В Немерле ансэйфа вообще нет. Плюс нет и ряда известных грабель C# (пристуствующих с рождения).
Но ты то вроде о сложности говорил? C# 3.0 несомннено сложнее C# 1.0. Вот по твоей логике и выходит, что его нельзя давать людям.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>Простой пример. Макрос Accesor порождающий свойство по полю. Предположим, что мы хотим изменить имя своайства. Что для этого должен сделать рефакторер?
Д>Допустим, мы стоим на месте в коде, где используется это свойство. Кликаем на него, рефакторер прыгает на место в коде, где определено это поле. А юзер пусть сам разбирается, что с этим макросом делать. Это — самый простой вариант.
1. Зачем прыгать? Нужно, например, имя изменить.
2. Как узнать, что код порожден конкретным макросом?
Д>Можно конечно придумать варианты посложнее — например, чтобы каждый макрос сообщал IDE о доступных для него операциях рефакторинга. Но овчинка не стоит выделки, ИМХО.
Вот незнаю. Может и стоит. А может стоит просто сделать так, чтобы для каждого применения макроса было известно что он за код породил.
VD>>Нет четкой корелляции между макросом и кодом им порожденным. Этот код потенциально может быть вообще новым классом.
Д>А по хорошему, должна быть. IDE нужно иметь точную информацию, "кто кого породил" , чтобы рефакторинг мог нормально работать.
Осталось придумть "как?"
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я уж как нибудь разберусь, тем более что я никого в переходе на личности не обвиняю. Ты лучше за собой последи.
Вот и я разберусь. А ты соотвественно следи лучше за сабой. ОК?
AVK>Именно. В непринужденной форме за пивом мы общались с Клеменсом, но это никого не заинтересовало.
Жаль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>неопытным солдатам оружия в руки вообще не дают. Только молоток, чтобы добивать упавших монстров Д>А тех, кто раздает BFG кому попало — под военный трибунал
Не, это опытным оружия не дают. Самые опытные обходятся саперной лопаткой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Я думаю, что MS элементарно не может это сделать, но делает грозный вид и прикрывается подобными легендами. Дарней прав. При ближайшем рассмотрении у новых продуктов MS столько недоделок, косяков в дизайне и порой просто глюков, что диву даёшься.
Ну, с тем компилятором на С++ что в Роторе вообще расширяемость должна доваться с огромными страданиями.
Я так понимаю, что мысли переписать компилятор на компонентных технологиях уже есть. Так что через 5 лет может что-то и увидим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK! Вы писали:
AVK>P.S. Много разговаривали с Клеменсом Вастерсом (он нынче program manager WCF). Описывать долго, так что если у кого есть какие вопросы — могу попробовать ответить.
Андрей, у меня детский вопрос.
Примерно с какого рейтинга (со скольких тысяч оценок) полученного на РСДНе я смогу разговаривать с такими людьми =)?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IT, Вы писали:
IT>>Были бы серьёзные изъяны — нашли бы без сомнения. Вон Скалу в соседнем топике уже пинают вовсю
VD>Где? Интересно...
Здравствуйте, VladD2, Вы писали:
VD>Осталось придумть "как?"
IDE всё равно ведь надо строить дерево кода, чтобы рефакторинг работал. Нет особой проблемы добавлять в это дерево код, которого нет в исходнике в явном виде, потому что он порождается макросом. То есть при парсинге кода, вероятно, нужно будет исполнять код встреченных в нем макросов и полученные результаты помещать в дерево. И помечать эти узлы специальным образом.
Здравствуйте, VladD2, Вы писали:
Д>>неопытным солдатам оружия в руки вообще не дают. Только молоток, чтобы добивать упавших монстров Д>>А тех, кто раздает BFG кому попало — под военный трибунал
VD>Не, это опытным оружия не дают. Самые опытные обходятся саперной лопаткой.
Здравствуйте, anvaka, Вы писали:
A>Примерно с какого рейтинга (со скольких тысяч оценок) полученного на РСДНе я смогу разговаривать с такими людьми =)?
Да в принципе ни с какого... Он пообщал приложить все усилия для того чтобы приехать в Москву во время WinFX тура, и пока я бегал за пивом, Андрюха уболтал его прийти после выступления на встречу rsdn-овской юзер группы, чтобы пообщаться в более неформальной обстановке.
Так что, надо всего лишь ходить на встречи RSDN UG...
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>Осталось придумть "как?"
Д>IDE всё равно ведь надо строить дерево кода, чтобы рефакторинг работал. Нет особой проблемы добавлять в это дерево код, которого нет в исходнике в явном виде, потому что он порождается макросом. То есть при парсинге кода, вероятно, нужно будет исполнять код встреченных в нем макросов и полученные результаты помещать в дерево. И помечать эти узлы специальным образом.
Согласен, но не появятся ли проблемы с производительностью такого рефакторинга (в С++ препроцессор как раз вышел боком для рефакторинг примочек)? И не получится ли так, что использовав ("засветив" ) в каком-то месте единожды одн из сильносвязанных классов в макросе, этот класс становится недоступным для рефакторнга?
Здравствуйте, Cyberax, Вы писали:
C>А где о них объявления бывают?
Как правило в форуме UG, и совершенно точно на сайте UG (http://rsdn.gotdotnet.ru), но он сейчас валяется, обещают что поднимут к двум часам дня. Там же темы докладов, и если зарегистрироваться, то можно голосовать и получать уведомления по почте...
Здравствуйте, prVovik, Вы писали:
V>Согласен, но не появятся ли проблемы с производительностью такого рефакторинга (в С++ препроцессор как раз вышел боком для рефакторинг примочек)?
А деваться все равно особо и некуда... других нормальных вариантов я не вижу. А у С++ другие проблемы — переусложненность и неоднозначность синтаксиса, в основном. Производительность среди них далеко не самая важная.
V>И не получится ли так, что использовав ("засветив" ) в каком-то месте единожды одн из сильносвязанных классов в макросе, этот класс становится недоступным для рефакторнга?
Здравствуйте, VladD2, Вы писали:
AVK>>А как в Nemerle эти проверки добавить? Чтобы не новый AST генерить, а контроллировать существующий?
VD>Это можно. Только вопрос расплывчатый.
Ну хорошо, более конкретно. Предположим нужно гарантировать отсутствие ключевых слов, не входящих в заранее заданный список.
Здравствуйте, VladD2, Вы писали:
VD>Тут нужно определить, что ты считашь опасными консрукциями (для начала). В Немерле ансэйфа вообще нет.
Ансейф ерунда. Ключик убрал и никакого ансейфа. Я имею ввиду другое — отсутствие конструкций навроде шаблонов С++, которые способны с благими намерениями сделать код нечитаемым.
VD>Но ты то вроде о сложности говорил? C# 3.0 несомннено сложнее C# 1.0.
Здравствуйте, Дарней, Вы писали:
V>>Согласен, но не появятся ли проблемы с производительностью такого рефакторинга (в С++ препроцессор как раз вышел боком для рефакторинг примочек)?
Д>А деваться все равно особо и некуда... других нормальных вариантов я не вижу. А у С++ другие проблемы — переусложненность и неоднозначность синтаксиса, в основном. Производительность среди них далеко не самая важная.
Может быть... Но компиляторы С++ и рефакторинг тулзы для него отличаются сильной тормознутостью. И не в первую очередь из-за препроцессора.
V>>И не получится ли так, что использовав ("засветив" Image ) в каком-то месте единожды одн из сильносвязанных классов в макросе, этот класс становится недоступным для рефакторнга?
Д>не совсем понял... можешь пояснить?
Допустим, у нас есть класс А, котогрый активно используется в крупном проекте. Есть Вася, помошник третьего заместителя стажера-программиста, который где-то далеко-далеко, глубоко-глубоко сгенерировал с помощью макроса безобидный с виду прокси-класс для класса "А". Вроде бы как это никого не должно было бы никого коснуться, но Самый Главный Программист очень удивиться, когда попытается переименовать какой-нибудь метод класса "А". Он не сможет этого сделать из-за использования где-то Васей макроса. Таким образом, сигнатуры элементов класса "А" очень легко и "прозрачно" блокируются и становятся недоступными для автоматического рефакторинга.
Здравствуйте, prVovik, Вы писали:
V>Допустим, у нас есть класс А, котогрый активно используется в крупном проекте. Есть Вася, помошник третьего заместителя стажера-программиста, который где-то далеко-далеко, глубоко-глубоко сгенерировал с помощью макроса безобидный с виду прокси-класс для класса "А". Вроде бы как это никого не должно было бы никого коснуться, но Самый Главный Программист очень удивиться, когда попытается переименовать какой-нибудь метод класса "А". Он не сможет этого сделать из-за использования где-то Васей макроса. Таким образом, сигнатуры элементов класса "А" очень легко и "прозрачно" блокируются и становятся недоступными для автоматического рефакторинга.
да, это уже проблема.... надо думать
хотя, по хорошему, далеко не все макросы производят код, который должен референситься в явном виде снаружи
Здравствуйте, Дарней, Вы писали:
Д>хотя, по хорошему, далеко не все макросы производят код, который должен референситься в явном виде снаружи
Ну не скажи... Реализация многих паттернов потребует таких ссылок.
Здравствуйте, Дарней, Вы писали:
Д>IDE всё равно ведь надо строить дерево кода, чтобы рефакторинг работал. Нет особой проблемы добавлять в это дерево код, которого нет в исходнике в явном виде, потому что он порождается макросом. То есть при парсинге кода, вероятно, нужно будет исполнять код встреченных в нем макросов и полученные результаты помещать в дерево. И помечать эти узлы специальным образом.
Исправлять прийдется исходный код. Так что прийдется построить четкое соотвествие между "раскрытым" кодом и исходным. Что, как мне кажется, просто так сделать не выйдет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Может быть... Но компиляторы С++ и рефакторинг тулзы для него отличаются сильной тормознутостью. И не в первую очередь из-за препроцессора.
Рефакторинг-тулзов для Немерла нет. Но его компилятор работает довольно быстро. Так что есть надежда, что со скоростью все будет ОК.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну хорошо, более конкретно. Предположим нужно гарантировать отсутствие ключевых слов, не входящих в заранее заданный список.
Это обеспечить не сложно. Создать метаатрибут который в самом начале пробежится по всем типам и поищет определения переменных по некоторому паттерну.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ансейф ерунда. Ключик убрал и никакого ансейфа.
Хм. А тебе не кажется, что такой же аргумент можно применить и к тем же макросам?
AVK> Я имею ввиду другое — отсутствие конструкций навроде шаблонов С++, которые способны с благими намерениями сделать код нечитаемым.
Макросы С++ создают проблемы не сами по себе, а своей убогостью. В них нет средств контроля происходящего (они работают с текстом). Они не гигееничны (легко сделать трудный в понимании конфликт). И они переопределяемы (что сбивает с толку).
VD>>Но ты то вроде о сложности говорил? C# 3.0 несомннено сложнее C# 1.0.
AVK>Нет, я говорил не о сложности.
Тогда о чем?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Я вообще-то с тобой не спорил. Ясогласился с GlebZ по поводу того, что язык выпускается с недоработанными фичами.
AVK>В ответ на мое сообщение, в котором я написал, что далеко не все фичи там недоделаны. Потому и говорю, что не читаешь то, на что отвечаешь.
Ладно, это все рассплывчато. Лично мне не нравится, что вообще есть явные недоработки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Ансейф ерунда. Ключик убрал и никакого ансейфа.
VD>Хм. А тебе не кажется, что такой же аргумент можно применить и к тем же макросам?
У компилятора Nemerle есть ключик, запрещающий макросы? Ну илди хотя бы макросы ввиде ключевых слов?
VD>>>Но ты то вроде о сложности говорил? C# 3.0 несомннено сложнее C# 1.0.
AVK>>Нет, я говорил не о сложности.
VD>Тогда о чем?
Здравствуйте, AndrewVK, Вы писали:
AVK>У компилятора Nemerle есть ключик, запрещающий макросы? Ну илди хотя бы макросы ввиде ключевых слов?
Макросы подключаются через ключ. Есть ключ отключающий стандартные макросы. И нет никаких проблем сделать ключ отключающий синтаксические макросы.
AVK>О побочных эффектах.
Подразумеваемых?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
По поводу доступа к анонимным типам появилось немножечко больше информации. Главная проблема их реализации в том, что анонимные типы могут быть использованы не в том модуле, в котором объявлены. Иными словами, одинаковые анонимные типы, объявленные в разных сборках, будут в рантайме разными типами. Следовательно, для полноценной поддержки кортежей нужно менять рантайм. Так что в первой версии LINQ полноценных кортежей, похоже, не будет, придется для экспорта описывать типы руками.
Здравствуйте, AndrewVK, Вы писали:
AVK>По поводу доступа к анонимным типам появилось немножечко больше информации. Главная проблема их реализации в том, что анонимные типы могут быть использованы не в том модуле, в котором объявлены. Иными словами, одинаковые анонимные типы, объявленные в разных сборках, будут в рантайме разными типами. Следовательно, для полноценной поддержки кортежей нужно менять рантайм. Так что в первой версии LINQ полноценных кортежей, похоже, не будет, придется для экспорта описывать типы руками.
Надо было не выпендриваться с именами полей в анонимных типах, тогда и проблем не было бы. Ведь классические кортежи не с дуру придумали такими какие они есть. Они внутри просто описываются через джененики.
Да и странно слышать от разработчиков дотнета о том, что им нужно менять рантайм. В чем проблема-то? Пусть меняют раз надо. Сделают патчь, обратно совместимый с FW 2.0 и нет проблем.
Когда они планируют выпуск LINQ-а?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Надо было не выпендриваться с именами полей в анонимных типах, тогда и проблем не было бы. Ведь классические кортежи не с дуру придумали такими какие они есть.
Вообще-то классические кортежи вполне себе содержат имена полей. В классической реляционной алгебре, кстати, на этой одноименности много чего построено — к примеру оператор естественного соединения. VD>Они внутри просто описываются через джененики.
Имхо нужно просто делать анонимный тип вот так:
namespace System
{
public class Tuple<T1, T2, T3>
{
protected T1 _f1;
protected T2 _f2;
public Tuple(T1 f1, T2 f2) { _f1 = f1; _f2 = f2; }
public Tuple(Tuple source): this(source._f1, source._f2) {}
}
}
namespace MyCode
{
public class MyAnonymousRecord : Tuple<string, int>
{
public string Name { get { return _f1; }}
public int Count { get { return _f2; }}
}
}
Т.е. есть встроенный набор туплов нужной размерности, а конкретный аноним будет наследоваться от этих туплов и заниматься переименованием. При этом анонимные типы с одинаковой сигнатурой становятся совместимыми, пусть и не одинаковыми.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Надо было не выпендриваться с именами полей в анонимных типах, тогда и проблем не было бы. Ведь классические кортежи не с дуру придумали такими какие они есть. Они внутри просто описываются через джененики.
Не согласен. Анонимные типы внутри выглядят простои понятно, а вот кортежи без именованных свойств запутывают код.
VD>Да и странно слышать от разработчиков дотнета о том, что им нужно менять рантайм.
От разработчиков компилятора.
VD> В чем проблема-то? Пусть меняют раз надо.
Было принято решение о том, что в Orcas рантайм кардинально менятся не будет, максимум выйдет сервис пак.
VD>Когда они планируют выпуск LINQ-а?
На данный момент вместе с Orcas. Т.е. либо в конце 2006, либо в начале 2007. Это релиз. Ближайший CTP должен выйти в течение месяца.
Здравствуйте, Sinclair, Вы писали:
S>Т.е. есть встроенный набор туплов нужной размерности, а конкретный аноним будет наследоваться от этих туплов и заниматься переименованием. При этом анонимные типы с одинаковой сигнатурой становятся совместимыми, пусть и не одинаковыми.
Нет, в твоем варианте они совместимыми не становятся. Ты сам можешь придумать массу примеров, когда несовместимость вылезет.
Здравствуйте, AndrewVK, Вы писали: AVK>Нет, в твоем варианте они совместимыми не становятся.
Ну, я подразумевал наличие implicit операторов конверсии из Tuple<>. AVK>Ты сам можешь придумать массу примеров, когда несовместимость вылезет.
Разве что в массивах
Впрочем, ты прав — получается сильно много костылей без значительных преимуществ.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>Надо было не выпендриваться с именами полей в анонимных типах, тогда и проблем не было бы. Ведь классические кортежи не с дуру придумали такими какие они есть. S>Вообще-то классические кортежи вполне себе содержат имена полей. В классической реляционной алгебре, кстати, на этой одноименности много чего построено — к примеру оператор естественного соединения.
Причем тут "В классической реляционной алгебре"?
Я говорил про классическую реализацию кортежей в функциональных языках. В том же COmega кортежи были с безымянными полями вроде. И никому это не мешало. Ребята решили рацушку ввести и получили кучу несовместимостей.
VD>>Они внутри просто описываются через джененики. S>Имхо нужно просто делать анонимный тип вот так: S>
S>namespace System
S>{
S> public class Tuple<T1, T2, T3>
S> {
S> protected T1 _f1;
S> protected T2 _f2;
S> public Tuple(T1 f1, T2 f2) { _f1 = f1; _f2 = f2; }
S> public Tuple(Tuple source): this(source._f1, source._f2) {}
S> }
S>}
В Немерле почти так и сделано. Только _f2 публичные, что естественно.
S>namespace MyCode
S>{
S> public class MyAnonymousRecord : Tuple<string, int>
S> {
S> public string Name { get { return _f1; }}
S> public int Count { get { return _f2; }}
S> }
S>}
S>
А это уже лишнее. Я конечно понимаю и оцениваю стремление дать имена полям кортежей, но откровенно говоря и без этого не плохо. А полноценные имена дейсвтительно требуют поддержки от рантайма, что верно заметили разработчики C#-а.
S>Т.е. есть встроенный набор туплов нужной размерности, а конкретный аноним будет наследоваться от этих туплов и заниматься переименованием. При этом анонимные типы с одинаковой сигнатурой становятся совместимыми, пусть и не одинаковыми.
Да, можно было вообще приведение типов сварганить. Только кривь это все и куча побочных проблем гарантируется.
Чистых решений два:
1. Введиние анонимных типов в рантайм.
2. Использование проверенного временем подхода с безымянными полями.
Лично я не понимаю почему было не остановится на втором варинте. В конце концов никто не страдает от того, что параметры методов не указываются явно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не согласен.
Значит у нас разные мнения.
AVK> Анонимные типы внутри выглядят простои понятно, а вот кортежи без именованных свойств запутывают код.
Ты меня конечно извини, но по-моему. запутывание высасано из пальца. Я в последнее время читаю много кода с тюплами и проблем не вижу. В коде все ясно и понятно.
Более того... Не знаю виноваты ли в этом тюплы, общие характеристики языка или просто умение авторов писать внятный код, но в последнее время я много читаю исходники Немероловского компилятора и постоянно ловлю себя на мысли, что даже без коментариев я отлично понимаю, что делает код. Декларативность очень высокая. В Шарповских исходниках такого же объема я запутался бы куда быстрее. И это при том, что у Шарпа супер IDE обеспечивающая охринительную навигацию по коду.
В общем, по-моему, tuple-ы нужно было вводить в язык просто для концептуальной стройности. Они решают тучу идеологических пробелм. Например, описание функций становится кристальным как слеза "tuple -> tuple".
Причем я не против если появиласб бы возможность определять подвиды tuple-лов с именованными членами. Но для этого действительно нужна поддержка рантайма. Это должно быть как функциональный тип и делегат. Другими словами tuple с именованными полями должен являться уточнением обычного tuple-а, как делегат является уточнением функционального типа. C# много потерял из-за отсуствия концептуальной законченности в этих вопросах.
VD>>Да и странно слышать от разработчиков дотнета о том, что им нужно менять рантайм.
AVK>От разработчиков компилятора.
Ты меня конично извини, но люди вроде Хейгельберга и Коробкина входят в любые комнаты любых групп разработки связанных с дотнетом без стука. И это не так проблема кторую они не могли бы решить.
VD>> В чем проблема-то? Пусть меняют раз надо.
AVK>Было принято решение о том, что в Orcas рантайм кардинально менятся не будет, максимум выйдет сервис пак.
Значит невреное решение приняли. В результате ведь в язык вводится концептуально незаконченная возможность. Это еще может боком в будущем выйти. Ведь это тот самый путь С++ который привел язык к монстроидальности.
VD>>Когда они планируют выпуск LINQ-а?
AVK>На данный момент вместе с Orcas. Т.е. либо в конце 2006, либо в начале 2007. Это релиз. Ближайший CTP должен выйти в течение месяца.
Хм. Это значит за год они не могут в рантайм изменение внести? Во, блин, дают! А чем же они там занимаются?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>> Анонимные типы внутри выглядят простои понятно, а вот кортежи без именованных свойств запутывают код.
VD>Ты меня конечно извини, но по-моему. запутывание высасано из пальца.
Я тебя конечно извиню, но нет, не из пальца. Более того — объявить десяток Tuple<T1, T2, ...> можно и сейчас, и точно так же можно их спокойно использовать в LINQ.
VD>Более того... Не знаю виноваты ли в этом тюплы, общие характеристики языка или просто умение авторов писать внятный код, но в последнее время я много читаю исходники Немероловского компилятора
ЗАДОЛБАЛ!!!
AVK>>От разработчиков компилятора.
VD>Ты меня конично извини, но люди вроде Хейгельберга и Коробкина входят в любые комнаты любых групп разработки связанных с дотнетом без стука.
А в комнату тех людей, которые решили, что серьезных изменений рантайма в Orcas и Vista не будет?
VD>Значит невреное решение приняли.
Не факт. Им в итоге деньги надо зарабатывать.
AVK>>На данный момент вместе с Orcas. Т.е. либо в конце 2006, либо в начале 2007. Это релиз. Ближайший CTP должен выйти в течение месяца.
VD>Хм. Это значит за год они не могут в рантайм изменение внести? Во, блин, дают! А чем же они там занимаются?
Здравствуйте, AndrewVK, Вы писали:
AVK>Я тебя конечно извиню, но нет, не из пальца. Более того — объявить десяток Tuple<T1, T2, ...> можно и сейчас, и точно так же можно их спокойно использовать в LINQ.
Ага. А на goto и if-ах можно и паттерн-матчинг, и хвостовую рекурсию сэмулировать. Вот толко это уже не жизнь, а издевательство над собой. А так, да. Нет проблем. На Тьюринг-полном языке можно все.
VD>>Более того... Не знаю виноваты ли в этом тюплы, общие характеристики языка или просто умение авторов писать внятный код, но в последнее время я много читаю исходники Немероловского компилятора
AVK>ЗАДОЛБАЛ!!!
Чем, простите? И почему никто не задалбывает упоминанием Шарпа? Естить пример, его и пирвожу. Был бы это С++ привел бы его. Но вот извини из языков которыми пользуюсь тюплы есть толко в одном.
VD>>Ты меня конично извини, но люди вроде Хейгельберга и Коробкина входят в любые комнаты любых групп разработки связанных с дотнетом без стука.
AVK>А в комнату тех людей, которые решили, что серьезных изменений рантайма в Orcas и Vista не будет?
А это что на основе астрологических прогнозов было решено? Или на религиозной почве? Если нет, то могут и передумать. Чистота и стройность языка важнее. Пошли же на изменение рантайма ради концептуальной полноты нулабл-типов прямо перед релизом? Ну, а тут в чем дело? Еще год как иминимум до релиза.
VD>>Значит невреное решение приняли.
AVK>Не факт. Им в итоге деньги надо зарабатывать.
По мне так факт. Хотя конечно каждый имеет право на лево. А вот то, что они от этого денег больше получат — то точно не факт.
AVK>Спроси у них.
Я к сожалению к ним без стука (да и со стуком) пока зайти не могу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ага. А на goto и if-ах можно и паттерн-матчинг, и хвостовую рекурсию сэмулировать.
А при чем тут кортежи?
AVK>>ЗАДОЛБАЛ!!!
VD>Чем, простите?
немерлёй.
VD> И почему никто не задалбывает упоминанием Шарпа?
Потому что этот топик о C#.
AVK>>А в комнату тех людей, которые решили, что серьезных изменений рантайма в Orcas и Vista не будет?
VD>А это что на основе астрологических прогнозов было решено? Или на религиозной почве?
Это было решено на основании необходимости выпустить продукт в срок.
VD> Если нет, то могут и передумать. Чистота и стройность языка важнее.
Для тебя. А для них важнее заработать денег (и выпустить Висту в срок).
VD> Пошли же на изменение рантайма ради концептуальной полноты нулабл-типов прямо перед релизом? Ну, а тут в чем дело?
В Висте.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
VD>>Ага. А на goto и if-ах можно и паттерн-матчинг, и хвостовую рекурсию сэмулировать.
AVK>А при чем тут кортежи?
При том, что эмуляция кортэжей на базе дженерик-классов или структур это такая же порнография.
VD>> И почему никто не задалбывает упоминанием Шарпа?
AVK>Потому что этот топик о C#.
Мы вообще-то говорили о кортежах которых в C# еще нет и довольно логично, что когда ты начал обсуждать недостатки кортежей с безымянными членами, тебе привели пример из языка где одные уже есть и во всю используются.
Вообще чем дальше тем больше C# будет сравниваться с Немерлом, так как языки во многом близки, и все развитие C# идет по пути который Немерле уже прошел.
C#, С++ или Руби на этом форуме упомянаются куда чаще. Причем в большинсве случаев противопоставляются. На то это и филосфия.
AVK>Это было решено на основании необходимости выпустить продукт в срок.
Напомню, что дата выпуска еще не извесна, и она точно будет не раньше чем в следующем году. Так что на отмазку это не тянет.
VD>> Если нет, то могут и передумать. Чистота и стройность языка важнее.
AVK>Для тебя.
Для языка. Ну, и для меня естественно, так как я являюсь одним из его пользователей и сторонников.
AVK> А для них важнее заработать денег (и выпустить Висту в срок).
Виста никаким боком к языку отношения не имеет. Ее и с C# 2.0 можно выпускать. Фрэймворки, как ты знашь, живут параллельно.
Да и опять же за год уж такую мелочь можно было реализовать.
VD>> Пошли же на изменение рантайма ради концептуальной полноты нулабл-типов прямо перед релизом? Ну, а тут в чем дело?
AVK>В Висте.
А мне кажетчя в другом. Ботся они чего-то или банально не видят, что решение не полноценное выходит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>> А для них важнее заработать денег (и выпустить Висту в срок).
VD>Виста никаким боком к языку отношения не имеет.
Зато имеет отношение к новой студии. Orcas собственно и выпускается как средство разработки под Vista, а не как независимый релиз.
VD>Да и опять же за год уж такую мелочь можно было реализовать.
Не думаю что это мелочь.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Зато имеет отношение к новой студии. Orcas собственно и выпускается как средство разработки под Vista, а не как независимый релиз.
Язык не должен привязываться к студиям или ОСям. Иначе это уже походит на стачу объектов к коммунистическим праздникам.
VD>>Да и опять же за год уж такую мелочь можно было реализовать.
AVK>Не думаю что это мелочь.
Что, ввести некий кэш типов и сопоставление типов из сборки с ним — это большая задача? Даже мсил править не прийдется.
Я бы просто формировал имя в стиле __UnnamedType_имяТипСвойства1_имяТипСвойстваX, добавл бы флажок говорящий, что тип анонимный и сделал бы помену ссылки на тип при первом обращении к нему.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
Детский сад какой-то 
1.1.4 stable rev. 510
Мы уже победили, просто это еще не так заметно...
