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

AG>Надеюсь что любой грамотный программист напишет вот так:

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

Мой поинт был в том, что выражение:

if (i != array1.Length - 1)

гораздо сложнее, чем:

if (i != 0)

Поэтому, если "императивный программист" выбирает сложные пути даже в простых программах, то точно так же он будет выбирать сложные пути и в функциональных программах.

Производительность и пр. не имеет к этому никакого отношения.

Здравствуйте, Чистяков Влад (VladD2), Вы писали:

ЧВV>Статья:
ЧВV>LINQ как шаг к функциональному программированию

Автор(ы): Чистяков Влад (VladD2)
Дата: 26.01.2009
Цель данной статьи – объяснить читателю незнакомому с ФП, что такое функциональный подход, какие он дает преимущества, и как его можно использовать с помощью LINQ и C# 3.0.
Кроме того, эта статья дает некоторое понимание того, как работает «LONQ to Object» и на каких принципах он основан.

Кстати, хочется спросить, а почему возвращаемые значения все время присваиваются как var, в результате я о типе могу лишь догадываться (компилятор то тип знает, а вот я не знаю)? Имхо очертененно уменьшает читаемость текста. Я один такой, кто б предпочел это ключевое слово не использовать без крайней необходимости (и если б использовал, то добавлял бы префиксы или постфиксы к имени, что приходится делать в языках с динамической типизацией чтоб не огрести потом проблем)? Может мне объяснить сакральный смысл использования var везде где только можно?

Здравствуйте, Влад.

в статье написано:

К сожалению, в .NET нет реализации однонаправленного связанного списка.
Разве это не есть реализация однонаправленного связанного списка. Появилось кажись в версии 2.0

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

D>Разве это не есть реализация однонаправленного связанного списка. Появилось кажись в версии 2.0
Нет. Там же написано "Represents a doubly linked list". Двусвязный так чтэ...

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

AG>Надеюсь что любой грамотный программист напишет вот так:

AG>

AG>var sb = new StringBuilder();
AG>for (int i = 0; i < array1.Length; i++)
AG>{
AG>    if (i != 0)
AG>    sb.Append(", ");
AG>    sb.Append(array1[i]);
AG>}
AG>result = sb.ToString();
AG>

Ну а я надеюсь, что любой грамотный программист напишет вот так:

result = string.Join(", ", array1);

P.S. Все украдено до нас.

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

AG>>var sb = new StringBuilder();
AG>>for (int i = 0; i < array1.Length; i++)
AG>>{
AG>>    if (i != 0)
AG>>    sb.Append(", ");
AG>>    sb.Append(array1[i]);
AG>>}
AG>>result = sb.ToString();

M>Ну а я надеюсь, что любой грамотный программист напишет вот так:

M>result = string.Join(", ", array1);

M>P.S. Все украдено до нас.

Всё не так просто: а если array1 массив не строк, а каких-то объектов с переопределённым ToString?

result = string.Join(", ", Array.Convert(array1, x => x.ToString()));

А если размер массива достаточно велик, что бы делать его копию?

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

_FR>Всё не так просто: а если array1 массив не строк, а каких-то объектов с переопределённым ToString?
_FR>

_FR>result = string.Join(", ", Array.Convert(array1, x => x.ToString()));
_FR>

_FR>А если размер массива достаточно велик, что бы делать его копию?

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

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

_FR>Всё не так просто: а если array1 массив не строк, а каких-то объектов с переопределённым ToString?
Если бы, да кабы, до во рту росли грибы В данном конкретном случае — лучше сделать нельзя.
P.S. Я просто хотел в шуточной форме вернуть дискуссию в русло ФЯ.

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

E>Идентификатор seed при вызове func -- это ошибка или что-то другое?

Проблемы копи-пэста. Рефлектор такой код декомпилирует не качественно. Пришлось руками декомпилировать. Ну, и решил сэкономить. Там не только сид лишний. Там еще первый элемент должен быть отдельно взят. Исправим...

E>PS. Из статьи можно было бы смело выкинуть, как минимум, 1/3 текста при сохранении той же информативности.

Будешь писать сам — выклинишь. А это моя статья, мой стиль и мой подход к изложению.

E>PPS. По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".

Больше конкретики, плиз. Если какие-то места задевают, можно подумать об их замене. А так... это не критика, а наезд.

E>PPPS. Надеюсь, что 90% императивных программистов все-таки пишут так:
Надеюсь, что по прочтении этой статьи хотя бы 10% начнут писать подобный код в функциональном стиле.
Остальное — не важные детали.

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

_>Жаль про join не рассказали ничего.

join — это уже расширение выходящее за рамки функционального подхода.

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

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

ЧВV>>Статья:
ЧВV>>LINQ как шаг к функциональному программированию

Автор(ы): Чистяков Влад (VladD2)
Дата: 26.01.2009
Цель данной статьи – объяснить читателю незнакомому с ФП, что такое функциональный подход, какие он дает преимущества, и как его можно использовать с помощью LINQ и C# 3.0.
Кроме того, эта статья дает некоторое понимание того, как работает «LONQ to Object» и на каких принципах он основан.

E>Кстати, хочется спросить, а почему возвращаемые значения все время присваиваются как var, в результате я о типе могу лишь догадываться (компилятор то тип знает, а вот я не знаю)? Имхо очертененно уменьшает читаемость текста. Я один такой, кто б предпочел это ключевое слово не использовать без крайней необходимости (и если б использовал, то добавлял бы префиксы или постфиксы к имени, что приходится делать в языках с динамической типизацией чтоб не огрести потом проблем)? Может мне объяснить сакральный смысл использования var везде где только можно?

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

Если вопрос тебя действительно интересует, то давай начнем с вопросов к тебе.
1. Попробуй пройтись по статье и найти все места где тип переменных не очевиден?
2. Задумывался ли ты над тем, что вывод типов есть не только для переменных объявленных с использованием var, но и при вызове методов (особенно обобщенных)? Чем, скажем вот этот код:

PrintSeq(array1.Reverse().Where((name, i) => i % 2 == 0));

лучше чем вот этоти:

var result = array1.Reverse().Where((name, i) => i % 2 == 0);
PrintSeq(result);

?
3. Почему поборники типизации переменных спокойно пишут SQL-запросы не указывая типов для возвращаемых колонок и при этом не возмущаются по поводу потери информации?

Если ты попытаешся найти ответы на эти вопросы, то скорее всего усомнишся в своем мнении.

От себя могу сказать только одно. По программировав с годик на языке программирования поддерживающем вывод типов, начинаешь относиться к аннотации типов значительно спокойнее и возвещение. Со временем приходит понимание, что главное, чтобы код был понятным тебе и окружающим. А всякие мелочи вроде аннотации типов и даже кошерность названий переменных — это все пуританство и борьба с ветряными мельницами.

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

E>компилятор то тип знает, а вот я не знаю?

А зачем тебе его знать? Меньше будешь знать, крепче будешь спать. Пишем «var result = ...», затем где-то «result.», и вот после этой точки IDE выдаёт список методов — и этого достаточно. А что там возвращается — IEnumerable<T>, Querable<T>, SomeProxyIterator<T> — избыточная информация, она засоряет код и делает его менее устойчивым к изменениям.

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

VD>Нет не один. Есть еще много людей которые не могут переступить через свои привычки. Но со временем ваш лагерь будет рядеть. Уж такова природа человеческая. Сначала человек воспринимает все новое в штыки, а потом начинает считать это новое само собой разумеющимся.
Это новое старо как мир . В языках с динамической типизацией уже лет 20 считают, что лучше var ничего нет, и не будет.

VD>Если вопрос тебя действительно интересует, то давай начнем с вопросов к тебе.
VD>1. Попробуй пройтись по статье и найти все места где тип переменных не очевиден?
Очевиден то он очевиден, но это напрягаться надо. И нет гарантии что где-то внутри цепочки вызовов тип не поменяется, более того, он меняется (дергается toString).

VD>2. Задумывался ли ты над тем, что вывод типов есть не только для переменных объявленных с использованием var, но и при вызове методов (особенно обобщенных)? Чем, скажем вот этот код:
VD>

VD>PrintSeq(array1.Reverse().Where((name, i) => i % 2 == 0));
VD>var result = array1.Reverse().Where((name, i) => i % 2 == 0);
VD>PrintSeq(result);
VD>

VD>?
Именно из соображений плохой читаемости я в основном предпочитаю второй тип записи (естественно не var, а имя типа). Пишу первым способом только что-то тривиальное, из соображений чтоб места было меньше (например частичный перенос данных из одного объекта в другой type1.setName1(type2.getName2())).

VD>3. Почему поборники типизации переменных спокойно пишут SQL-запросы не указывая типов для возвращаемых колонок и при этом не возмущаются по поводу потери информации?
А я кстати возмущаюсь, что для типов возвращаемых колонок не указывается тип, когда приходится пользоваться SQL. Именно по этому предпочитаю вместо его HQL. Но и в HQL не все хорошо, в случае с наследованием сущностей далеко не тривиально узнать кого ж я получил из запроса и могу ли я дернуть соответствующее свойство — мне очень не хватает возможности указания типа даже в HQL запросе.

VD>От себя могу сказать только одно. По программировав с годик на языке программирования поддерживающем вывод типов, начинаешь относиться к аннотации типов значительно спокойнее и возвещение. Со временем приходит понимание, что главное, чтобы код был понятным тебе и окружающим. А всякие мелочи вроде аннотации типов и даже кошерность названий переменных — это все пуританство и борьба с ветряными мельницами.
JavaScript и VBScript пойдет? 2 года опыта достаточно? Я как раз попрограммировав на этих языках наоборот на строгую типизацию намолиться не могу.

И относительно того, что при написании все будет хорошо, студия по нажатию точка все возможные варианты скажет. Код в основном читается, а не пишется. Один раз написал, 100 раз потом прочитал. Типы я обычно помню наизусть, а вот что принимает и что возвращает функция я обычно не помню, особенно если это не ясно из функции. В случае если все аргументы var и возвращается туда же, мне придется лезть смотреть что это за функция и что она принимает. Я бы запомнил что есть такая функция неосознанно, если б все типы ее я видел, тут же я через месяц вряд ли вспомню что такая функция уже есть, где-то я ее уже вижу и напишу свой велосипед.

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

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

E>Типы я обычно помню наизусть, а вот что принимает и что возвращает функция я обычно не помню, особенно если это не ясно из функции.
Зато это помнит студия, вы же не распечатки читаете. Достаточно навести курсор и все расскажет и покажет. Кроме того перегрузка методов позволяет создавать короткие вызовы, с 2-3 очевидными параметрами, а пере передавать десятки null для необязательных параметров.

E>В случае если все аргументы var и возвращается туда же, мне придется лезть смотреть что это за функция и что она принимает.
Вообще-то C# имеет строгую типизацию, поэтому типы параметров и возвращаемого значения всегда известны, даже если не указаны явно. И снова подсказке среды разработки помогает.

E>Я бы запомнил что есть такая функция неосознанно, если б все типы ее я видел, тут же я через месяц вряд ли вспомню что такая функция уже есть, где-то я ее уже вижу и напишу свой велосипед.
Это ваши особенности памяти, другим людям они несвойственны.
Чтобы не писать постоянно велосипеды надо правильно группировать функции. Во-первых собираит их в классы по функциональному назначению, во-вторых использовать extension-методы.

В одном проекте видел несколько функций валидации email, которые были в неймспейсах
<project name>.Utils
<project name>.<еще что-то>.StringUtils
<project name>.Web.Utils
И у ваех был параметр String и возвращаемое значение String, но это никому не помогло.

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

E> В языках с динамической типизацией уже лет 20 считают, что лучше var ничего нет, и не будет.
В языках с динамической типизацией совсем другой var. C# по прежнему статически типизирован и все типы выводятся на этапе копиляции.

E>JavaScript и VBScript пойдет? 2 года опыта достаточно?
Нет, не подойдет, так как там var совсем другой.

E>Я как раз попрограммировав на этих языках наоборот на строгую типизацию намолиться не могу.
Строгая типизация никуда не делась.

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

IB>В языках с динамической типизацией совсем другой var. C# по прежнему статически типизирован и все типы выводятся на этапе копиляции.
IB>Нет, не подойдет, так как там var совсем другой.
IB>Строгая типизация никуда не делась.
Это я прекрасно знаю. Но ... код визуально выглядит очень похоже на языки с динамической типизацией. И если распечатать код чтоб почитать перед сном — без поддержки студии понимать его будет значительно сложнее.

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

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

IB>>В языках с динамической типизацией совсем другой var. C# по прежнему статически типизирован и все типы выводятся на этапе копиляции.
IB>>Нет, не подойдет, так как там var совсем другой.
IB>>Строгая типизация никуда не делась.
E>Это я прекрасно знаю. Но ... код визуально выглядит очень похоже на языки с динамической типизацией.
Эх, что же вы бедете делать когда появится dynamic (который кстати тоже является строгим типом)?

E>И если распечатать код чтоб почитать перед сном — без поддержки студии понимать его будет значительно сложнее.
А таким кто-то занимается?

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

G>Эх, что же вы бедете делать когда появится dynamic (который кстати тоже является строгим типом)?
Предпочту не использовать без необходимости, а не начну лепить везде, чтоб показать что я новую версию языка освоил .

G>А таким кто-то занимается?
А как-же? Простейший пример — когда задают вопрос на форуме или пишут статью, копипастят исходники, и те, кто читают, к исходникам доступа не имеют и им труднее понять получается. Когда просят отревьюить код тоже частенько бросают его в аську. А там никакой студии нет встроенной.

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

G>>А таким кто-то занимается?
E>А как-же? Простейший пример — когда задают вопрос на форуме или пишут статью, копипастят исходники, и те, кто читают, к исходникам доступа не имеют и им труднее понять получается.
Что-то я не видел примеров на формуме где отсуствие аннотации типов мешало бы чтению. Кроме специално обфуцированых.

E>Когда просят отревьюить код тоже частенько бросают его в аську. А там никакой студии нет встроенной.
По куску текста можно только алгоритм увидеть, а в алгоритмах как раз конкретные типы — не главное.
Рвьювить на предмет дизайна по небольшому куску кода не сильно получится.

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

G>Эх, что же вы бедете делать когда появится dynamic (который кстати тоже является строгим типом)?

В каком смысле "строгим"? Как-раз таки это позднее связывание.