Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, mrTwister, Вы писали:
WH>>>В данном случае я прекрасно знаю и работал с обоими подходими. T>>Это ещё один стандартный аргумент в холиварах. WH>Ты конечно можешь и дальше отвергать факты этой фразой но факты от этого не перестанут быть фактами ...
Факт заключается в том, что это твое личное мнение (что обсуждаемый синтаксис тебе не мешает). Дак вот, факт наличия у тебя такого личного мнения я не отрицаю.
Здравствуйте, mrTwister, Вы писали:
T>Вот, ты проблем не видишь. А если мы запишем туже программу так, то увидишь?
def keyToValMap = SCG.Dictionary();
keyToValMap["asd"] = 1 : byte;//говорим компилятору что 1 у нас имеет тип byte.
def size = keyToValMap["asd"];
def arr = array(size); // expected int, got byte- in value reference: System.Byte is not a subtype of System.Int32 [simple require]
Я ее и без указания типов увижу...
Я же говорю ты не работал с языками в которых вывод типов есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Я ее и без указания типов увижу... WH>Я же говорю ты не работал с языками в которых вывод типов есть.
Offtop: неужели в Nemerle размер массива можно указывать только в Int32? В любом случае, к выводу типов это не имеет никакого отношения.
Но тем неменее, если вернуться с небес на землю (в смысле к C#), то вышеуказанный пример наглядно демонстрирует, как использование var помешало сделать ошибку очевидной.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Кэр, Вы писали:
Кэр>>Иван, а ты еще в Редмонде? IB>Уже нет, мы сейчас с AVK и Голлумом в джерси, в гостях у IT =)
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, WolfHound, Вы писали:
WH>>Я ее и без указания типов увижу... WH>>Я же говорю ты не работал с языками в которых вывод типов есть. T>Offtop: неужели в Nemerle размер массива можно указывать только в Int32? В любом случае, к выводу типов это не имеет никакого отношения.
T>Но тем неменее, если вернуться с небес на землю (в смысле к C#), то вышеуказанный пример наглядно демонстрирует, как использование var помешало сделать ошибку очевидной.
Если сравнивать C# с языками с более мощным выводом типов, то оказывается что проблема не в var, а в неявном приведении типов в C#.
Здравствуйте, AndrewVK, Вы писали:
AVK>Отсутствие возможности воспользоваться максимально полным контрактом.
Ну что это за аргумент? Почему он относится к локальным переменным и не относится к параметрам?
AVK>Это обеспечивает максимальную гибкость и надежность кода. Есть, ЕМНИП, довольно строгое доказательство сего на основе LSP.
А вдруг все же ТИП? Ссылку давай.
AVK>А теперь встречный вопрос — а зачем обобщать тип локальной переменной?
Затем же, зачем обобщают тип параметра. Различие только количественное.
Здравствуйте, samius, Вы писали:
S>Если сравнивать C# с языками с более мощным выводом типов, то оказывается что проблема не в var, а в неявном приведении типов в C#.
То есть хотя и не использование вывода типов вообще, но все же использование вывода типов в C# может привести к проблемам?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, WolfHound, Вы писали:
WH>>Конечно FileStream. ... Компилятор только параметры генерика вывел.
I>Никакой "конечности" тут нет, компилятор точно также мог вывести наиболее общий достаточный тип.
Зачем может понадобится компилятору мухлевать с явно указанным типом локальной переменной?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Если сравнивать C# с языками с более мощным выводом типов, то оказывается что проблема не в var, а в неявном приведении типов в C#.
I>То есть хотя и не использование вывода типов вообще, но все же использование вывода типов в C# может привести к проблемам?
Да, я считаю что именно неявное преобразование типов в C# делает вывод типов в нем менее предсказуемым чем в Nemerle и F#.
Выше был приведен пример когда переполненный byte мог уйти в длину массива. Но шутка может быть еще хуже:
var size = keyToValMap["size"];
var sizeDiv2 = size / 2;
Console.WriteLine(Math.Sqrt(sizeDiv2));
Смотря на этот код без подсказок среды мы не можем предсказать, какой тип хранится в size. Мы его можем поделить на 2 (а хрен знает, это целая 2 или с плавающей точкой) и можем подать в метод, который принимает double.
Языки без неявного приведения типов не стерпят это безобразие. Потому — да, в C#-е вывод типов проблемнее.
Здравствуйте, samius, Вы писали:
S>Зачем может понадобится компилятору мухлевать с явно указанным типом локальной переменной?
Затем чтобы IDE показывало тип Stream читающему программу и последнему было бы без просмотра дальнейшего кода ясно, что методы специфичные для FileStream не используются.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Mystic, Вы писали:
M>>Оптимизация связанная с многопоточностью, обычно либо уровнем выше (например, пул потоков на сервере), либо на уровне качественного изменения алгоритмов, кеширования и т. п. Для качественной оптимизации, данных, которые получает LINQ, может и не хватить. Ну и в таком случае я предпочитаю критические участки писать на чистом С, где все под контролем. 0>Не соглашусь. Пулы потоков, всякие "Task manager`ы", "Scheduler`ы" и прочие "тяжеловесные" решения, организующие параллельные вычисления, достаточно неуклюжи. Они хороши для организации архитектуры прогаммы, сервера, там, какого-нибудь, но неудобны при написании вычислительных алгоритмов. Очень хочется чего-то более простого и органичного.
Я обращал внимание на то, что оптимизация, связанная с многопоточностью, уже может быть выполнена уровнем выше. Например, у нас есть сервер, есть пул потоков, каждая сессия работает в своем собственном потоке. Если при этом еще и сессия начнет плодить потоки дл организации вычислений, то работа сервера в целом может замедлится. Или, например, при написании шахматной прораммы, нет никакого смысла делать генератор ходов многопоточным, потому что распараллеливание естественным образом возникает при переборе вариантов на верхнем уровне.
Вообще, потребность в оптимизации вычислительных алгоритмов возникает не часто. И первый шаг в такой оптимиации происходит на алгоритмическом уровне: вместо того, чтобы выполнять циклы быстро и параллельно, мы избавляемся от циклов, строим заранее таблицы для часто повторяющихс вычислений и т. д. и т. п.
0>Идея переписать на "чистом С" критические участки мне тоже не нравится. При таком раскладе придется самому "с нуля" писать инфраструктуру для распараллеливания, что, по-сути, есть велосипед. К тому же хочется максимально отделить спецификацию алгоритма от тонкостей реализации параллелизма, что бы можно было заменять инфраструктуру параллелизма без переписывания вычислительного кода.
Я тут скорее всего даже не про распараллеливание как таковое, потому как для меня это самый последний шаг в оптимизации. Вначале надо выжать по максимуму из самого алгоритма. А уже потом параллелизм на последнем шаге. И в четко выбранном месте.
M>>Ну и повышение уровня абстракции также не бесплатно. В свои проектах я нередко с повышением уровня абстракции заходил в тупик, потому что поддерживать становилось все сложнее. 0>Вообще-то странно, я всегда думал, что поддерживаемость программы прямо пропорциональна высоте абстракций, на которых она построена. При условии, конечно, что абстракции выбраны правильно
Вот большая проблема как раз в правильном выборе. Возникают "дыры", с которыми потом усиленно борешься.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mystic, Вы писали:
M>>Ну и в таком случае я предпочитаю критические участки писать на чистом С, где все под контролем.
AVK>Упомянутый уже здесь Эрик Мейер, когда рассказывал про некоторые применения Rx, говорил, что он недостаточно умен, чтобы написать аналогичное без линка. И я ему почму то верю.
Так тут все просто: не будет хватать моего ума, будут возникать проблемы, буду смотреть в сторону того, как их решать. А если проблем нет и пока не предвидится?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Зачем может понадобится компилятору мухлевать с явно указанным типом локальной переменной?
I>Затем чтобы IDE показывало тип Stream читающему программу и последнему было бы без просмотра дальнейшего кода ясно, что методы специфичные для FileStream не используются.
И что это даст читающему программу в отношени локальной переменной?
Здравствуйте, Mystic, Вы писали:
M>Так тут все просто: не будет хватать моего ума, будут возникать проблемы, буду смотреть в сторону того, как их решать. А если проблем нет и пока не предвидится?
Если проблем нет, то, с большой вероятностью, это означает что ты их пока не видишь
... << RSDN@Home 1.2.0 alpha 4 rev. 1458 on Windows 7 6.1.7600.0>>
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>И что это даст читающему программу в отношени локальной переменной?
I>Отсутствие необходимости просматривать дальнейший код, чтобы убедиться в том, что методы специфичные для FileStream не используются.
И что же даст знание о том что специфичные методы не используются для локальной переменной?
Здравствуйте, olegkr, Вы писали:
IT>>>Кто именно воспользуется? L>>Любой твой коллега или ты сам.
O>Страшно жить, когда от коллег и себя защищаться приходится.
Почитал этот тред и все нелестные высказывания в адрес тех, кто LinQ как следует не знает, а делает выводы.
Я его тоже не знаю, и, чтобы не получить в свой адрес нелестные высказывания, выводы делать не буду.
У меня вопрос к тем, кто считает, что он LinQ знает.
Сформулируйте, когда LinQ стоит применять и когда его применение нецелесообразно.
...
В любом случае, к выводу типов это не имеет никакого отношения.
Ну ладно — стучитесь в следующий раз если что 
