Здравствуйте, VladD2, Вы писали:
VD>Это ничего не меняет. Это демонстрирует, что слова Гапертона поддерживаемые тобой заблуждение. И косвенно указывает на бессмысленность и демогогичность обсуждения устроенного вами.
Нами??? По-моему, ты первый взвился. Я ошибаюсь?
ГВ>>Да и вообще, вопрос не в том, кто что породил (прям Библия, не меньше), а зачем это было нужно. VD>Вопрос бы один и он был очень прост. Является ли ЛИНК средством рассчитанным исключительно (или в основном) на работу с РСУБД или нет. Ответ на этот вопрос лично для меня очевиден — нет.
А нафиг всё же впёрся LINQ, если функциональный стиль и так поддерживается C# 3.0? Неужели бродилку по IEnumerable<> (к которой ты хочешь свести назначение LINQ) так сложно написать, что из-за неё стоит заморачиваться с введением аж модификаций в синтаксис C#?
ГВ>>Хм. Может, я чего-то не понимаю, но по-моему, всё, что ты тут сказал прямо доказывает, что LINQ предназначен в первую очередь для работы с SQL-серверами. VD>Ген. Иди купи себе какой-нибудь учебник по логике. Прочти в нем раздел посвященный причино-следсвенной связи. Иначе с тобой просто невозможно говорить.
Угу-угу, кто б советовал...
VD>Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра?
Осталось задаться вопросом, что считать ветром, а что — деревьями. Ты, судя по всему, считаешь ветром лозунг "ФП — в массы" и ещё какую-то квази-альтруистическую риторику, я — что "надо состыковаться с SQL-сервером". Чей ветер стабильнее?
VD>Такая же фигня и с линком. Следствием его универсальности является возможность в том числе обрабатывать из хранимые в СУБД. Из факта "ЛИНК позволяет работать с данными из РСУБД" ни как не следует, что линк "предназначен в первую очередь для работы с SQL-серверами".
Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.
ГВ>>Зачем иначе огород городить с ExpressionTrees?
VD>Очевидно для того, чтобы можно было в рантайме проанализировать ЛИНК-запрос и что-то сделать на его основе. Частным случаем этого "что-то" является переписывание запроса в SQL и выполнение его некоторым сервером. Опять же ничто не говорит в пользу гипотезы "LINQ предназначен в первую очередь для работы с SQL-серверами".
А вот теперь подумай — на кой шут городить огород с генерацией/анализом AST, если у нас единая среда исполнения? Чтобы дать юзерам "визуальные языки"? Ещё какая-нибудь абстрактная идея света в массы?
VD>Если придерживаться твоей извращенной "логики" (в кавычках так как этот по сути алогизм), то можно заключить что ЛИНК, в первую очередь, предназначен для распределения вычислений по разным серверам, так как он позволяет это делать и есть люди которые этим пользуются.
С LINQ-ом вообще всё не слишком понятно обстоит — его, похоже, будут набивать фичами, которые больше некуда воткнуть.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, yuriylsh, Вы писали:
Y>А что дальше делать с полученным AST — это уже дело провайдера. Напрмер, реализовать LINQ to LLBLGen, LINQ to Twitter, LINQ to Google,...
Правильно. Это есть вполне нормальное следствие обобщения изначально узконаправленного средства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, yuriylsh, Вы писали:
Y>>А что дальше делать с полученным AST — это уже дело провайдера. Напрмер, реализовать LINQ to LLBLGen, LINQ to Twitter, LINQ to Google,...
ГВ>Правильно. Это есть вполне нормальное следствие обобщения изначально узконаправленного средства.
D_>Для сохранения состояния в линке есть Aggregate. Хотя, бесспорно, с помощью цикла было бы удобнее. D_>
D_> var array = new[] {1, 2, 3, 7, 8, 9, 10};
D_> var result = array.Aggregate(new
D_> {
D_> PreviouslyTaken = array.FirstOrDefault() - 2,
D_> PreviousElement = array.FirstOrDefault() - 2,
D_> Result = (IEnumerable<int>)new int[0]
D_> },
D_> (ag, i) => new
D_> {
D_> PreviouslyTaken = (i - 1 == ag.PreviousElement) && ag.PreviousElement != ag.PreviouslyTaken
D_> ? i : ag.PreviouslyTaken,
D_> PreviousElement = i,
D_> Result = (i - 1 == ag.PreviousElement && ag.PreviousElement != ag.PreviouslyTaken)
D_> ? ag.Result.Concat(new [] {i}) : ag.Result
D_> },
D_> ag => ag.Result);
D_>
Ну, если написать код несколько ближе к описанию задачи и не увлекаться погоней за очень понятными именами переменных, то вряд ли решение основанное на цикле будет проще:
var ary = new[] { 1, 2, 3, 7, 8, 9, 10 };
var result = ary.Aggregate(new { Prev = 0, Skip = true, Res = new List<int>() }, (acc, cur) =>
acc.Skip ? new { Prev = cur, Skip = false, acc.Res }
: acc.Prev + 1 == cur ? new { Prev = cur, Skip = true, Res = acc.Res.AddElem(cur) }
: new { Prev = cur, Skip = false, acc.Res },
ag => ag.Res);
foreach (var item in result)
Console.WriteLine(item);
Правда тут потребуется метод расширения позволяющий добавлять элемент в List<T> и возвращающий экземпляр этого же списка.
Тоже самое на Nemerle не требует даже наличия метода расширения:
Определенно более продвинутый вывод типов, использование блоков кода как выражений и наличие кортежей шарпу не помешали бы. Жаль, что его авторы так близоруки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>1. Можно ли с помощью линк обрабатывать коллекции в памяти.
ГВ>Да.
VD>>2. Можно ли с помощью линка обрабатывать ХМЛ.
ГВ>Да.
VD>>3. Есть ли в ЛИНК-е что-то что может быть применимо толко для РСУБД и не применимо для других источников данных?
ГВ>Я таких не припомню, во всяком случае.
Значит ответ тоже "да".
ГВ>Хотя LINQ и получен обобщением проблем взаимодействия с РСУБД.
Никто не спрашивал как получен линк. Так что это позволю себе проигнорировать эту фантазию. В прочем, с удовольствием послушаю логически корректное доказательство этой гипотезы.
VD>>4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?
ГВ>По сравнению с какими?
А что в Шарпе есть какие-то средства отличные от циклов?
ГВ>Но. См. ответ на следующий вопрос.
VD>>4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?
ГВ>Вопрос поставлен некорректно. Как понимать "более удобную для обработки объектов в памяти нежели для работы с СУБД"? Критерии сравнения "более менее" каковы?
Это вопрос к Гапертону. Это его цитата которую ты так ревностно защищаешь.
ГВ>Вот ещё пара встречных вопросов:
Я просил ответить на мои вопросы.
В прочем полученных ответов уже достаточно чтобы сделать вывод о том, что утверждения Гапертона ложны. А ЛИНК как ни странно является универсальным средством обработки данных.
Что и следовало доказать.
Так что остается последний вопрос.
Неужели тебе приятнее выглядеть человеком не владеющим азами логического мышления нежели человеком который ошибался, но понял свои ошибки?
ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?
Как-то так (Nemerle, так как писать на нем приятнее):
using System.Collections.Generic;
using System.Console;
using System.Linq;
def lst = [1, 2, 3, 7, 8, 9, 10];
def (_, _, res) = lst.Aggregate((0, true, List()), ((prev, skip, res), cur) =>
if (skip) (cur, false, res)
else if (prev + 1 == cur) (cur, true, { res.Add(cur); res })
else (cur, false, res));
WriteLine($"..$res");
Объясняю преимущества перед использованием циклов.
1. Отсутствуют специальные случае вроде пустого массива которые можно забыть проверить.
2. Отсутствует работа с индексами, так что ошибка не приведет к генерации исключений в непротестированных случаях.
3. Решение задачи близко к ее постановке. Мы описывает, что хотим получить, а не то как мы это хотим получить. Нам не нужно думать о переборе значений, мы думаем только об алгоритме.
Проблема только одна. Чтобы прочесть и понят данный код нужно иметь некоторый опыт использования ФВП и абстрагирования алгоритма от его реализации.
ГВ>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.
Не понял саму постановку задачи.
Собственно, жду твою императивную реализацию обоих задачек. Первой просто для сравнения. Второй хотя бы чтобы понять, что ты имел в виду.
ГВ>Как ты понимаешь, традиционным for обе задачи решаются тривиально.
Не не понимаю. Я понимаю, что ты постарался подобрать задачку которая по твоим соображениям плохо решается с помощью линковских функций. Более правильным направлением было бы выбрать задачи обработки матриц. В прочем и там можно использовать линк, хотя не так уж и осмысленно.
Вопрос не в том удалось тебе или не удалось придумать такие задачки.
Вопрос в том зачем ты это пытался сделать?
Ведь очевидно, что есть масса задач которые решаются с помощью линка в десятки раз удобнее. Будешь спорить?
И эти задачи никак не связаны с СУБД тем более с реляционными.
А раз так, то говорить о какой-то привязанности линка к РСУБД — это просто идти против базовых концепций логики. Говоря простыми словами — это полный идиотизм.
Так что ты еще не понял, и что ты пыташся доказать?
Или ты все же давно все понял и просто троллишь специально не желая мыслить логически?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Скажем, есть некая иерархия, начальник-подчинённые. Я хочу получить точно такое же дерево, как и исходное, но не с самими персонами, а с их именами. Так не работает текущая реализация, верно? VD>Не верно. И я уже сказал почему.
Я уже запутался Не верно — т.е. текущая реализация так работает что ли? Ты же сам пишешь, что функция нерекурсивная. Или "не верно" относится к чему-то другому?
VD>Встречный вопрос. В Хаскеле ты бы справился с обработкой дерева?
Конечно! Это же обычный map. Только для деревьев. Вот код:
query = fmap name
В общем я почитал (спасибо за ссылки). LINQ ограничивает результат конкретным типом (IEnumerable/IQueryable). В этом смысле Select ни разу ни функтор. Вернее, зависит от реализации.
В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип
public static F<B> Select<F,A,B>(Function<A,B> f, F<A> struc)
Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Нами??? По-моему, ты первый взвился. Я ошибаюсь?
Что значит "взвился". Если ты не заметил. Я вообще отвалил от этого глупого спора.
ГВ>А нафиг всё же впёрся LINQ, если функциональный стиль и так поддерживается C# 3.0?
Ты кажется любишь пообсуждать что от чего было пораждено. Так вот C# 3.0 такой какой он есть в основном благодаря LINQ.
Возможности для программирования в функциональном стиле были и в 2.0. Но удобным это стало только в 3.0, так как:
А. Язык расширели выводом типов, локаничными лямбдами и деревьями выражений.
Б. Появилась библиотека ФВП входящая в LINQ. Без нее программировать в функциональном стиле невозможно. Конечно можно было бы написать свою, но рядовой программист это не понятнул бы. Появилось бы море разных реализацию не совместимых между собой (смотрим на С++). LINQ же предоставляет отлично реализованную библиотеку максимально полно покрывающую обще потребности. И получилось все так неплохо потому что делали LINQ под контролем очень хороших функциональщиков которые в отличие от многих крикунов с нашего сайта понимают не букву ФП, а его суть.
ГВ>Неужели бродилку по IEnumerable<> (к которой ты хочешь свести назначение LINQ) так сложно написать, что из-за неё стоит заморачиваться с введением аж модификаций в синтаксис C#?
Представь себе не просто. Как и написание любой библиотеки данная задача требует системного подхода, анализа, немалых знаний и опыта. У автора LINQ-а все это было, так как он чуть ли не является соавтором хаскеля.
ГВ>Угу-угу, кто б советовал...
Я тебе советую. Ты уж извини, что это звучит резко и даже оскорбительно. Но твои суждения не выдерживаю ни какой критики. Если это не намеренный троллинг, то это это огромные проблемы.
VD>>Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра?
ГВ>Осталось задаться вопросом, что считать ветром, а что — деревьями.
Ну, пошла полная софистика.
ГВ>Ты, судя по всему, считаешь ветром лозунг "ФП — в массы" и ещё какую-то квази-альтруистическую риторику, я — что "надо состыковаться с SQL-сервером". Чей ветер стабильнее?
Я не намерен отвечать на очередную попытку увести обсуждение черт знает куда.
VD>>Такая же фигня и с линком. Следствием его универсальности является возможность в том числе обрабатывать из хранимые в СУБД. Из факта "ЛИНК позволяет работать с данными из РСУБД" ни как не следует, что линк "предназначен в первую очередь для работы с SQL-серверами".
ГВ>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном.
Да, ну? А что же за "факты" ты использовал?
И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод?
VD>>Очевидно для того, чтобы можно было в рантайме проанализировать ЛИНК-запрос и что-то сделать на его основе. Частным случаем этого "что-то" является переписывание запроса в SQL и выполнение его некоторым сервером. Опять же ничто не говорит в пользу гипотезы "LINQ предназначен в первую очередь для работы с SQL-серверами".
ГВ>А вот теперь подумай — на кой шут городить огород с генерацией/анализом AST, если у нас единая среда исполнения? Чтобы дать юзерам "визуальные языки"? Ещё какая-нибудь абстрактная идея света в массы?
А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.
Использовать деревья выражений можно как угодно. Их можно трансформировать в рантайме и скомпилировать. На этом принципе, в не малой степени реализован тип dinamic в C# 4.0. Их можно использовать для генерации запросов к ООБД которая никогда не пользовалась реляционными принципами. Их можно вообще не использовать. Например, LINQ to Objects и LINQ to XML вообще их не использут, но при этом позволяют как использовать ФВП входящие в состав LINQ-а, так и синтаксические расширения языков.
VD>>Если придерживаться твоей извращенной "логики" (в кавычках так как этот по сути алогизм), то можно заключить что ЛИНК, в первую очередь, предназначен для распределения вычислений по разным серверам, так как он позволяет это делать и есть люди которые этим пользуются.
ГВ>С LINQ-ом вообще всё не слишком понятно обстоит — его, похоже, будут набивать фичами, которые больше некуда воткнуть.
Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.
Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным. А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Конечно! Это же обычный map. Только для деревьев. Вот код:
L>
L>query = fmap name
L>
L>В общем я почитал (спасибо за ссылки). LINQ ограничивает результат конкретным типом (IEnumerable/IQueryable). В этом смысле Select ни разу ни функтор. Вернее, зависит от реализации.
Разве fmap не зависит от реализации?
L>В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип
L>
L>Конечно! Это же обычный map. Только для деревьев. Вот код:
L>
L>query = fmap name
L>
А без fmap не справился бы?
L>В общем я почитал (спасибо за ссылки). LINQ ограничивает результат конкретным типом (IEnumerable/IQueryable). В этом смысле Select ни разу ни функтор. Вернее, зависит от реализации.
Там все несколько сложнее. Есть конкретные реализации завязанные на IEnumerable/IQueryable, а есть "query expression pattern" который абстрагирован от конкретики:
delegate R Func<T1,R>(T1 arg1);
delegate R Func<T1,T2,R>(T1 arg1, T2 arg2);
class C
{
public C<T> Cast<T>();
}
class C<T> : C
{
public C<T> Where(Func<T,bool> predicate);
public C<U> Select<U>(Func<T,U> selector);
public C<V> SelectMany<U,V>(Func<T,C<U>> selector, Func<T,U,V> resultSelector);
public C<V> Join<U,K,V>(C<U> inner, Func<T,K> outerKeySelector, Func<U,K> innerKeySelector, Func<T,U,V> resultSelector);
public C<V> GroupJoin<U,K,V>(C<U> inner, Func<T,K> outerKeySelector, Func<U,K> innerKeySelector, Func<T,C<U>,V> resultSelector);
public O<T> OrderBy<K>(Func<T,K> keySelector);
public O<T> OrderByDescending<K>(Func<T,K> keySelector);
public C<G<K,T>> GroupBy<K>(Func<T,K> keySelector);
public C<G<K,E>> GroupBy<K,E>(Func<T,K> keySelector, Func<T,E> elementSelector);
}
class O<T> : C<T>
{
public O<T> ThenBy<K>(Func<T,K> keySelector);
public O<T> ThenByDescending<K>(Func<T,K> keySelector);
}
class G<K,T> : C<T>
{
public K Key { get; }
}
Ты где-то видишь здесь IEnumerable/IQueryable?
L>В Haskell Select — это fmap (эндофунктор, отображение), поэтому его тип
L>
fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой?
Думаю, второе.
Потенциально конечно можно реализовать query expression pattern через рефлексию и ты получишь полный аналог fmap за исключением ограничений безопасности. Но оно надо, такое решение?
L>Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение.
В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.
Я же тебе хотел сказать о другом. В хаскеле вполне можно работат с деревьями без fmap. Более того скорее всего для реальной прикладной задачи ты как раз не будешь использовать fmap. Ты или напишешь рекурсивную функцию, или будешь работать с деревом используя знания о его структуре. Вот та же фигня и в линке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Собственно, жду твою императивную реализацию обоих задачек. Первой просто для сравнения. Второй хотя бы чтобы понять, что ты имел в виду.
и дальше по ветке. Вторую задачу я "снял с соревнований" — слишком неясная формулировка оказалась.
По остальным пунктам позже отвечу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.
Другой, но инкапсуляция все же есть. Это как если бы в C# все поля были открыты, но инкапсуляция бы обеспечивалась только тем, что у клиентского кода есть только интерфейс сущности и нет знаний о типе, его реализующем. У хаскеля роль интерфейсов играют классы типов. Чем не инкапсуляция?
Здравствуйте, lomeo, Вы писали:
L>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.
Gaperton, куда ж ты слился-то. Ты же так активно отстаивал, что состояние == мутабльность. А теперь так резко замолчал.
Здравствуйте, lomeo, Вы писали:
L>Поэтому давай не будем лить воду из пустого в порожнее.
Да я не против.
Просто ваш коллега настолько рьяно настаивал, что состояние — это неизменно мутабельность, что я начал сомневаться в здравом смысле. Но, судя по тому, что он не только не стал вам возражать, но и плюсует ваши посты, можно сделать вывод, что мы просто друг друга не до конца поняли.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Нами??? По-моему, ты первый взвился. Я ошибаюсь?
VD>Что значит "взвился". Если ты не заметил. Я вообще отвалил от этого глупого спора.
ГВ>>А нафиг всё же впёрся LINQ, если функциональный стиль и так поддерживается C# 3.0? VD>Ты кажется любишь пообсуждать что от чего было пораждено. Так вот C# 3.0 такой какой он есть в основном благодаря LINQ.
Угу. Вполне это допускаю, что ради интеграции LINQ пришлось доработать C#. Значит, -1 аргумент в пользу "благих намерений" MS.
VD>Возможности для программирования в функциональном стиле были и в 2.0. Но удобным это стало только в 3.0, так как: VD>А. Язык расширели выводом типов, локаничными лямбдами и деревьями выражений.
Угу-угу. Отображать структуру IL-кода прайвеси не позволяет, могут не понять. Потому пришлось городить дополнительный огород с отображаемыми выражениями. Между прочим, это самый простой и естественный способ построения развитого ORM даже средствами C++. Уж поверь мне на слово.
VD>Б. Появилась библиотека ФВП входящая в LINQ. Без нее программировать в функциональном стиле невозможно. Конечно можно было бы написать свою, но рядовой программист это не понятнул бы. Появилось бы море разных реализацию не совместимых между собой (смотрим на С++). LINQ же предоставляет отлично реализованную библиотеку максимально полно покрывающую обще потребности. И получилось все так неплохо потому что делали LINQ под контролем очень хороших функциональщиков которые в отличие от многих крикунов с нашего сайта понимают не букву ФП, а его суть.
Ёлки зелёные. Это никак не отражается на том назначении LINQ, которое (на мой взгляд) просвечивает у него через все дырки.
ГВ>>Неужели бродилку по IEnumerable<> (к которой ты хочешь свести назначение LINQ) так сложно написать, что из-за неё стоит заморачиваться с введением аж модификаций в синтаксис C#? VD>Представь себе не просто. Как и написание любой библиотеки данная задача требует системного подхода, анализа, немалых знаний и опыта. У автора LINQ-а все это было, так как он чуть ли не является соавтором хаскеля.
Ну, и я прекрасно понимаю автора. Под соусом адаптации к SQL построить довольно интересную штуковину. И ни на йоту оного автора не осуждаю. Я бы тоже так поступил на его месте. Тем более, что ФП-фичи и в самом деле довольно полезная штука. Как и ОО-фичи, если без излишней голубоглазости ими пользоваться.
ГВ>>Угу-угу, кто б советовал... VD>Я тебе советую. Ты уж извини, что это звучит резко и даже оскорбительно. Но твои суждения не выдерживаю ни какой критики. Если это не намеренный троллинг, то это это огромные проблемы.
Давай замнём этот вопрос для ясности. Так оно спокойней.
VD>>>Подумай на досуге является ли то, что деревья качаются при ветре доказательством того, что они созданы для создания ветра? ГВ>>Осталось задаться вопросом, что считать ветром, а что — деревьями. VD>Ну, пошла полная софистика.
Какая ж это софистика? Это сотая попытка прояснить действительные причины супротив вымышленных.
ГВ>>Ты, судя по всему, считаешь ветром лозунг "ФП — в массы" и ещё какую-то квази-альтруистическую риторику, я — что "надо состыковаться с SQL-сервером". Чей ветер стабильнее? VD>Я не намерен отвечать на очередную попытку увести обсуждение черт знает куда.
Иными словами, тебе плевать на установление действительных причин. Согласен, гораздо проще руководствоваться иллюзиями альтруизма MS.
ГВ>>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном. VD>Да, ну? А что же за "факты" ты использовал? VD>И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод?
Я очень хорошо знаю о проблеме ORM и соответствующих фактах наличия сторонних средств. И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо. Ещё я очень хорошо знаю, что под "источником данных" чаще всего подразумевается РСУБД, такова общая практика. Ещё я могу припомнить кое-что из своей практики, после всего этого, поверь, можно сделать очень много выводов.
ГВ>>А вот теперь подумай — на кой шут городить огород с генерацией/анализом AST, если у нас единая среда исполнения? Чтобы дать юзерам "визуальные языки"? Ещё какая-нибудь абстрактная идея света в массы? VD>А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.
Если тебе не надо об этом думать — никто тебя не заставляет. Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения. Только какой смысл при этом встревать с опровержениями высказываний других? Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем. А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор. Переубедить меня сможет, вполне вероятно, письмо Билла Гейтса, датированное 2001-м годом, где будет написано: "...we need to implement functional programming for our customers, are you know somebody good in functional languages development?" Если у тебя завалялось такое, то я с удовольствием соглашусь с твоими доводами. Если нет или потёр случайно — ну извини, я продолжаю считать, что первопричиной разработки LINQ явился OR-импеданс. Это просто, понятно и лишено обоснований с привлечением иррациональных соображений.
VD>Использовать деревья выражений можно как угодно. Их можно трансформировать в рантайме и скомпилировать. На этом принципе, в не малой степени реализован тип dinamic в C# 4.0. Их можно использовать для генерации запросов к ООБД которая никогда не пользовалась реляционными принципами. Их можно вообще не использовать. Например, LINQ to Objects и LINQ to XML вообще их не использут, но при этом позволяют как использовать ФВП входящие в состав LINQ-а, так и синтаксические расширения языков.
Для "как угодно" у них довольно узкий набор, хотя вполне достаточный для построения сложных выражений, не буду спорить. Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов. Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.
ГВ>>С LINQ-ом вообще всё не слишком понятно обстоит — его, похоже, будут набивать фичами, которые больше некуда воткнуть. VD>Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.
Ладно, согласен. Не набивают, а пришивают куда угодно. На основное соображение, оспариваемое без малого двумя сотнями сообщений это никак не влияет.
VD>Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным.
Вот за такую постановку задачи бьют канделябром. Исключение составляют совсем юные и синеглазые. Им можно изъясняться подобными оборотами.
VD>А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).
Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
и дальше по ветке. Вторую задачу я "снял с соревнований" — слишком неясная формулировка оказалась. VD>В приведенном сообщении полной реализации нет. Смотреть тонных вложенных сообщений нет никакого желания. Так что жду полного примера здесь.
Их там две. Ладно, цитирую:
// разdelegate void F<in T>(T arg);
static void sample1(int[] arr, F<int> func)
{
for(int i = 1; i < arr.Length; ++i)
{
if (arr[i] - arr[i - 1] == 1)
{
func(arr[i]);
++i;
}
}
}
// дваstatic IEnumerable<int> sample1b(IEnumerable<int> arr)
{
bool first = true;
int prev = 0;
foreach (int i in arr)
{
if (first)
{
first = false;
prev = i;
}
else if (i - prev == 1)
{
yield return i;
first = true;
}
else prev = i;
}
}
Куда уж полнее-то?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Как это вяжется с тем, что Linq, мол, предназначен для любых источников данных? Получается, что только для тех, которые сводятся к РСУБД-like. IT>>Ты можешь дать определение РСУБД-like типам данных? Гапертон не смог.
ГВ>В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД.
Дай ссылочку на твою теорию, я посмотрю. А то мне не понятно как внутри отношения (слова, которое означает 'связь, зависимость') могут отсутствовать связи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Куда уж полнее-то?
А ту где будет и массив и вывод результатов. Ты же просил решить задачу. Ну, вот и покажи ее полное решение.
А то как-то неудобно полную программу сравнивать с фрагментами реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да... и желательно решение без создания лишних функций. А то как-то не красиво получается сравнивать оверхэд создаваемый лишними функциями с решением умещающимся на четырех строках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не верно — т.е. текущая реализация так работает что ли? Ты же сам пишешь, что функция нерекурсивная. Или "не верно" относится к чему-то другому?
По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов. Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.
Если нам не помогут, то мы тоже никого не пощадим.
