Здравствуйте, mrTwister, Вы писали:
T>Ага, это все равно, что написать: "надо учиться писать код, чтобы в нём не было багов. Ставить вместо этого подпорки в виде статической типизации, автоматического управления памятью и пр. не имеет никакого смысла". С идеей, конечно, не поспоришь, но пользы от неё никакой.
Кто-то спорит с пользой статической типизации, сборки мусора и пр.?
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[18]: LINQ как шаг к функциональному программированию
Здравствуйте, Ziaw, Вы писали:
Z>Андаинг приводит такие шедевры читабельности, что просто диву даешься. Может быть у вас найдется хороший пример, где var делает код двусмысленным, а явное указание снимает данный недостаток?
var что-то_непонятное = GetЧтоТоНепонятное();
лэт ми спик фром май харт
Re[19]: LINQ как шаг к функциональному программированию
Здравствуйте, mrTwister, Вы писали:
H>>На Erlang нет ни одного варианта, просто нету анотаций типов. Мне не мешает.
T>С чего ты взял, что тебе это не мешает, ведь ты не пробовал программировать на эрланге с аннотацией типов?
А ты пробовал? С чего ты взял, что мне это надо попробовать именно на Erlang? На то есть С++, С#, Obj-C и другие, где есть аннотация типов. Везде синтаксис задания типа практически одинаковый. В чем вообще смысл вопроса?
Re[21]: LINQ как шаг к функциональному программированию
Стало, но не на много. По крайней мере можно открыть ЧтоТоНепонятное.cs и посмотреть, что там внутри.
Но случаи разные бывают. Не всегда имена методов идеальны, или не всегда понятна логика их работы. Вот еще пример:
var result = ValidateOrderLines(order);
Serialize(result);
лэт ми спик фром май харт
Re[12]: LINQ как шаг к функциональному программированию
Здравствуйте, hugo, Вы писали:
T>>С чего ты взял, что тебе это не мешает, ведь ты не пробовал программировать на эрланге с аннотацией типов?
H>А ты пробовал?
Нет, по-этому про эрланг я ничего и не пишу.
лэт ми спик фром май харт
Re[20]: LINQ как шаг к функциональному программированию
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, hugo, Вы писали:
T>>>С чего ты взял, что тебе это не мешает, ведь ты не пробовал программировать на эрланге с аннотацией типов?
H>>А ты пробовал?
T>Нет, по-этому про эрланг я ничего и не пишу.
А про что ты вообще пишешь? Я не понимаю смысла сказанного тобой Мне не нужно использовать аннотацию типов именно на Erlang, чтобы убедиться в том, что ее отсутствие там мне не мешает. Для этого мне достаточно опыта программирования на других языках, где она есть.
Re[24]: LINQ как шаг к функциональному программированию
Здравствуйте, mrTwister, Вы писали:
T>Этот код во-первых, хотя бы очень короткий, а во-вторых, не вводит переменную, которая непонятно как и для чего используется.
Вот и я говорю, лучше писать короткий и понятный код без аннотаций, чем непонятный и с аннотациями. В понятном коде аннотации больше мешают, в непонятном помогают очень слабо, а зачастую и отвлекают.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[11]: LINQ как шаг к функциональному программированию
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Ziggi111, Вы писали:
Z>>Можно. Ибо как уже писали выше, если функции обзывать не как попало, то всё понятно и без intellisense. Ну если конечно функция Дай_Хлеб() не возвращает колесо_от_самолёта.
T>Что возвращает "ExecuteSupercalifragilisticexpialidocious()"?
Судя по названию метода void. Иногда может возвращать true/false, как показатель успешности неуспешности выполения.
Re[13]: LINQ как шаг к функциональному программированию
Здравствуйте, mrTwister, Вы писали:
T>Причем intellicence доступен далеко не всегда. Например, он недоступен при мержевании, или сравнении версий исходников.
Так вот это и плохо. Все version control операции (merge, compare, review и т.д.) должны выполняться в IDE, и иметь прямую и полную поддержку всех её механизмов.
Re[3]: LINQ как шаг к функциональному программированию
U>>Здесь все прозрачно и может корректно работать на любой коллекции.
VD>Лучше говоришь? Ну, тогда попробуй свой вариант в действии. Тебя ждет сюрприз.
Мда... я был лучшего мнения об MS. Разложить столько граблей в одной функции это надо уметь. Считать initialValue по сути первым элементом коллекции это сильно, но мягко говоря неочевидно. Тогда да в реализации от МS нормального решения нет, использовать Aggregate можно только так:
string result = "";
if (array1.Count != 0)
result = array1.Aggregate((first, second) => first + ", " + second));
Что есть ужас.
Тем не менее написать реализацию без граблей вида Aggregate(T startValue, Func<T, T, T> func) вполне можно, но MS это не удалось.
Re[5]: LINQ как шаг к функциональному программированию
Здравствуйте, Undying, Вы писали:
U>Мда... я был лучшего мнения об MS. Разложить столько граблей в одной функции это надо уметь. Считать initialValue по сути первым элементом коллекции это сильно, но мягко говоря неочевидно.
Причем тут МС? Ты бы прочел бы статью еще раз обращая внимание на ее суть, а не на никому не нужные в данном случае оптимизации. Глядишь и вопросы такие не возникли бы.
U>Тогда да в реализации от МS нормального решения нет, использовать Aggregate можно только так:
U>
U> string result = "";
U> if (array1.Count != 0)
U> result = array1.Aggregate((first, second) => first + ", " + second));
U>
U>Что есть ужас.
Ужас в твоей голове. Шарп конечно не лучший ФП язык и его библиотеки не очень чисты, но тем не менее и на нем можно писать вполне себе функционально.
Ты тут споришь черт знает о чем, а главной сути статьи так и не понял. Ее суть подвигнуть людей мыслить функционально. Ты же четко демонстрируешь императивное мышление и вместо того чтобы попробовать изменить свои взгляды ввязываешся во флэймы о пользе и вреде явной аннотации типов.
U>Тем не менее написать реализацию без граблей вида Aggregate(T startValue, Func<T, T, T> func) вполне можно, но MS это не удалось.
Ну, конечно МС виновата в том, что кто-то глядя в книку видит фигу.
Если говорить о решении конкретной задачи — преобразовании последовательности в строку, то грамотным решением будет создание специализированных функций вроде:
А вот как их реализовать — это отдельный вопрос. Учитывая, что основная работа — это работа над своим проектом, то сначала их можно реализовать декларативно с применением LINQ-функций, а в последствии переписать императивно для большей скорости. При этом можно создать дополнительные перегрузки для специализированных коллекций вроде массивов. Это позволит еще больше поднять скорость в частных случаях.
Кстати, обрати внимание на вторую перегрузку. Она характерна тем, что позволяет задать функцию-конвертер. Это сделает решение намного более гибким. Ведь зачастую элементы коллекции требуется обрабатывать специальным образом.
Вот это уже есть проявление функционального мышления. Вместо геморроя связанного с разработкой ООП-решений достаточно просто передать лямбду которая решит вопрос сложного форматирования.
Aggregate же (ака Fold, reduce) полезен как универсальный заменитель циклов. При его использовании циклы сжимаются до декларации их сути.
К сожалению именно этого ты и не увидел. Зато усмотрел проблемы у МС. Меж тем в большинстве ФЯ вообще нет аналога Aggregate не принимающего начальное значение. Так что это своего рода расширение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
