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

WH>А то что не делает код понятнее мусор который делает код сложнее.

Сравниваем:

    Stream stream = new FileStream(...

    FileStream stream = new FileStream(...

    var stream = new FileStream(...

Кто тут сложнее?

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

WH>Статическая и динамическая типизция это резные вещи.

Согласен, кастинг доставаемых объектов еще и неэффективен и гораздо хуже чем использование FileStream там, где достаточно Stream. Тем не менее последнее тоже нехорошо.

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

I>

I>    Stream stream = new FileStream(...
I>    FileStream stream = new FileStream(...
I>    var stream = new FileStream(...
I>

I>Кто тут сложнее?
Первые два конечно.
И особенно очевидно это будет если имя типа будет длиннее да еще и с параметрами.
Например так:

    Dictionary<MySuperPuperType, MyHyperMegaType> dictionary = new Dictionary<MySuperPuperType, MyHyperMegaType>();
    var dictionary = new Dictionary<MySuperPuperType, MyHyperMegaType>();

а теперь немерле:

    def dictionary = Dictionary();

Ну как?

Единственное место где анотации типов полезны это публичный интерфейс.
Внутри методов они безполезны и как следствие вредны.

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

I>Согласен, кастинг доставаемых объектов еще и неэффективен и гораздо хуже чем использование FileStream там, где достаточно Stream. Тем не менее последнее тоже нехорошо.

Смахивает на паранойку, приобретённую тяжёлых и изнурительных боях

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

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

L>>И как вы защититесь от того, что кто-то не воспользуется вашим продвинутым списком, а задействует напрямую linq-коллекцию?

IT>Кто именно воспользуется?

Любой твой коллега или ты сам.

L>>Или опять будешь сказочки рассказывать про то, что у вас никто никогда не ошибается?

IT>Постоянно ошибаться — это наша профессия. Я вот, например, в предыдущем предложении слово 'ошибаться' сначала без мягкого знака написал. Но потом исправился и в релиз этот текст пошёл без этой ошибки.

И? Это к чему было написано? Как отследит тот факт, что использовалась не та коллекция?


IT>>>

IT>>>var customer = GetCustomers().FirstOrDefault();

IT>>>if (customer != null)
IT>>>    Console.WriteLine(customer.Name);
IT>>>

L>>>>Код читается хуже

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

Any — звучит естественно для любого человека.

L>>Совсем плохо. Не скомпилится даже.

IT>А ты попробуй. Кстати, если предыдущий код по-твоему компилировался, то в этом я добавил всего лишь одну пробельную строчку

Ну не знаюю по-моему между

var customers = GetCustomers();
if (customers.Any()) {
  Console.WriteLine(customers.First().Name);
}

и

var customer = GetCustomers().FirstOrDefault();

if (customer != null)
    Console.WriteLine(customer.Name);

различий все-таки больше, чем "одна пробельная строка".

IT>>>Переменных абсолютно столько же.
L>>А какого лешего ты убрал customers? Там может ниже код размером с пол-"Войны и Мира", где в каждой строчке customers — по пять раз.

IT>А зачем в этом коде этот мусор. Или ты переменные создаёшь на про запас?

Конечно, а ты разве нет? Вау.
Что же ты будешь делать, когда они закончатся?

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

WH>>Статическая и динамическая типизция это резные вещи.
I>Согласен, кастинг доставаемых объектов еще и неэффективен и гораздо хуже чем использование FileStream там, где достаточно Stream. Тем не менее последнее тоже нехорошо.
Хватит демагогию разводить.
Ты берешь не относящаяся к теме утверждение с котором не поспоришь, проводишь не корректные ассоциации и на их основе "доказываешь" свое ложное утверждение.
Такими методами со мной спорить бесполезно.

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

L>>>И как вы защититесь от того, что кто-то не воспользуется вашим продвинутым списком, а задействует напрямую linq-коллекцию?
IT>>Кто именно воспользуется?
L>Любой твой коллега или ты сам.

Страшно жить, когда от коллег и себя защищаться приходится.

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

WH>Ты берешь не относящаяся к теме утверждение с котором не поспоришь, проводишь не корректные ассоциации и на их основе "доказываешь" свое ложное утверждение.

Ну уж нет. Дело было так: я привел пример использования коллекций of Objects программистами в ответ на VladD2-овское "программистам по сути по фигу какой там тип у этой переменной". То есть в смысле, что мне по сути по фигу, по фигу ли по сути неким программистам, какой там тип у этой переменной. И независимо от мнения пофигных программистов полагаю, что в MSDN корректнее было написать Stream stream = new FileStream или, если уж на то пошло, var stream = new FileStream, но не FileStream stream = new FileStream создавая впечатление будто тут и вправду используются некие методы FileStream отсутствующие в Stream. Если тип указан, он должен быть выбран так, чтобы давать как можно меньше возможностей программисту, в идеале — только те, что используются.

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

0>>Вот тут я бы с тобой поспорил. Что происходит, при замене конструкций вида foreach на вызов функций linq2objects? Повышается уровень абстракции — ты не просто делаешь foreach, а применяешь к последовательности определенные преобразования, реализация которых скрыта. В чем профит? Появление Plinq дает ответ на этот вопрос.
VD>Фиг бы со всеми Plinq — ками. Главный профит в том, что код пишется на более высокоуровневых абстракциях. Их проще распознавать в коде, а значит проще понять что делает сам код. А Plinq и т.п. — это уже следствие.
Я с тобой согласен на 100%. Даже на 250%. Но мне часто встречаются собеседники не согласные с этим утверждением, так что я не рискую применять этот аргумент Вот и в этом топике мой один собеседник выразился в том духе, что повышение абстракции делает программу менее поддерживаемой. Я даже запнулся ответить.

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

I>Если тип указан, он должен быть выбран так, чтобы давать как можно меньше возможностей программисту, в идеале — только те, что используются.

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

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

M>Профит еще в тех же ленивых вычислениях, когда можно просто описать все действия, а сам LINQ уже выполнит только необходимое. Но все это не кажется чем-то уж крайне необходимым и полезным.
Где как. Во время отладки это вообще ОЧЕНЬ неудобно. И при обработке небольших коллекций особой роли не играет. А если речь идет о чем-то тяжелом, что еще не просто берется из памяти, а генерируется и вычитывается откуда-то, то ленивость может стать хорошим методом оптимизации.

M>Оптимизация связанная с многопоточностью, обычно либо уровнем выше (например, пул потоков на сервере), либо на уровне качественного изменения алгоритмов, кеширования и т. п. Для качественной оптимизации, данных, которые получает LINQ, может и не хватить. Ну и в таком случае я предпочитаю критические участки писать на чистом С, где все под контролем.
Не соглашусь. Пулы потоков, всякие "Task manager`ы", "Scheduler`ы" и прочие "тяжеловесные" решения, организующие параллельные вычисления, достаточно неуклюжи. Они хороши для организации архитектуры прогаммы, сервера, там, какого-нибудь, но неудобны при написании вычислительных алгоритмов. Очень хочется чего-то более простого и органичного.

Идея переписать на "чистом С" критические участки мне тоже не нравится. При таком раскладе придется самому "с нуля" писать инфраструктуру для распараллеливания, что, по-сути, есть велосипед. К тому же хочется максимально отделить спецификацию алгоритма от тонкостей реализации параллелизма, что бы можно было заменять инфраструктуру параллелизма без переписывания вычислительного кода.

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

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

WH>>Ты берешь не относящаяся к теме утверждение с котором не поспоришь, проводишь не корректные ассоциации и на их основе "доказываешь" свое ложное утверждение.

I>Ну уж нет. Дело было так: я привел пример использования коллекций of Objects программистами в ответ на VladD2-овское "программистам по сути по фигу какой там тип у этой переменной".

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

Я пишу:

def keyToValMap = Dectionary();
...
keyToValMap["key1"] = 123;
...
keyToValMap["key2"] = 65;
...
when (keyToValMap.Contains("key2"))
  doSomeWork();

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


I>...полагаю, что в MSDN корректнее было написать Stream stream = new FileStream или, если уж на то пошло, var stream = new FileStream, но не FileStream stream = new FileStream

Когда этот пример писали в шарпе просто не было еще var. А то как там они написали Stream или FileStream по сути не очень важно. Ведь разбирается другой вопрос. Хотя конечно примеры в журналах и документации становятся образцами для подражания. Вот только причем тут эта дискуссия? Она ведь не о журналах? Она о реальном коде. А в реальном коде я бы предпочел var. И мне плевать, что гда-то там есть базовый тип. Если мне станет это важно, я могу просто воспользоваться явным приведением типов.

I>создавая впечатление будто тут и вправду используются некие методы FileStream отсутствующие в Stream. Если тип указан, он должен быть выбран так, чтобы давать как можно меньше возможностей программисту, в идеале — только те, что используются.

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

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

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

Забавно. Я всегда считал наоборот. В прочем тут нужно смотреть на то, что вкладывается в понятие "абстракция". Можно ссылочку?

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

VD>Забавно. Я всегда считал наоборот. В прочем тут нужно смотреть на то, что вкладывается в понятие "абстракция". Можно ссылочку?
Re[5]: Linq : неудачный маркетинг?

Автор: Mystic
Дата: 19.02.10

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

VD>Забавно. Я всегда считал наоборот. В прочем тут нужно смотреть на то, что вкладывается в понятие "абстракция". Можно ссылочку?
здесь

Автор: Mystic
Дата: 19.02.10

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

0>А где можно посмотреть эту лекцию?
Боюсь, что нигде, помоему записи вообще не было, но если и велась, то скорее всего она будет под NDA.

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

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

A_S>>Select и SelectMany собственно и есть механизм построения монад + query syntax. я это и пытался сказать выше, просто не очень получилось))

S>Если что, об этом целый опус у меня в блоге. Можно покритиковать, кстати!

вот бы этот опус да превратить в статью на rsdn. нлядишь, и споров бы поубавилось)))

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

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

VD>>Или человек идиот и он будет раз за разом порождать не эффективные решения, или...

IT>Судя по тому, что они у себя бэбиситят девелоперов, первое.

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

А по поводу бебиситерства. У стартима Чаков Норрисов, видимо, даже тесторов нет и код сразу идет в продакшен. Ибо Чаку Норрису не нужны тестеры-бебиситтеры, которые ищут ошибки Чака Норриса. Ибо Чак Норрис никогда не ошибается.

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

S>Что линк это монады он неоднократно упоминал в лекциях по хаскелю. А нет ссылки на слайды? Правда я с Rx еще не знаком, только наслышан.
Если в разговоре с теми программистами, о которых я говорил в стартовом сообщении, упомянуть слово "монада", то беседа тут же прекратится

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

VD>

VD>def keyToValMap = Dectionary();
VD>...
VD>keyToValMap["key1"] = 123;
VD>...
VD>keyToValMap["key2"] = 65;
VD>...
VD>when (keyToValMap.Contains("key2"))
VD>  doSomeWork();
VD>

А что сделает keyToValMap при обращении по несуществующему ключу: сгенерирует исключение, или вернет null? Если бы там было написано Dictionary<Key,Value>, то у меня такой вопрос бы не возник.