Здравствуйте, Lloyd, Вы писали:
T>>Если без демонстрации, то хотя бы объясните в чём ухудшение поддержки? L>Это же очевидно: меньше информации выражено явно => сложнее разбираться.
Как раз наоборот. Меньше ненужной информации => проще разбираться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>Это же очевидно: меньше информации выражено явно => сложнее разбираться.
IT>Как раз наоборот. Меньше ненужной информации => проще разбираться.
Все верно, только тип не является ненужной информацией.
Здравствуйте, Lloyd, Вы писали:
L>>>Это же очевидно: меньше информации выражено явно => сложнее разбираться. IT>>Как раз наоборот. Меньше ненужной информации => проще разбираться. L>Все верно, только тип не является ненужной информацией.
Вопрос предпочтений. Мне лично в подавляющем большинстве случаев от типа ни холодно, ни жарко.
Если нам не помогут, то мы тоже никого не пощадим.
L>>>Это улучшения для разработки, но ухудшения для поддержки. А поддержка, как известнно, занимает гораздо больше времени и денег. И где тогда выигрышь?
T>>Допустим, что это упрощение разработки, но я продемонстрировал в чём именно улучшение. T>>Если без демонстрации, то хотя бы объясните в чём ухудшение поддержки?
L>Это же очевидно: меньше информации выражено явно => сложнее разбираться.
Из вашего утверждения можно сделать вывод, что управление памятью, закрытие хэндлов и прочий сахар — всё должно быть строго ручным. Или я что-то неправильно понял?
Вот если б вы сказали "меньше уместной/полезной информации", то тогда мы могли бы поспорить о том, всегда ли объявление типов промежуточных результатов является полезным/уместным. Не загораживают ли эти деревья лес.
И действительно, каждый явно объявленный тип — это как маленький юнит-тест. Что-то поменяли в другом месте — здесь тип не пропускает. Может помочь (быстрее) поймать некоторые ошибки. Но это уже очень тонкие материи *грамотного* использования инструмента. Иметь инструмент и вовремя использовать (а иногда не использовать) всё-таки лучше, чем не иметь его вовсе.
Здравствуйте, Temoto, Вы писали:
L>>Это же очевидно: меньше информации выражено явно => сложнее разбираться.
T>Из вашего утверждения можно сделать вывод, что управление памятью, закрытие хэндлов и прочий сахар — всё должно быть строго ручным. Или я что-то неправильно понял?
Нет, вы неправильно поняли.
T>Вот если б вы сказали "меньше уместной/полезной информации", то тогда мы могли бы поспорить о том, всегда ли объявление типов промежуточных результатов является полезным/уместным.
Вот уже и какие-то промежуточные результаты пошли. Продолжайте в том же духе .
Здравствуйте, Wolverrum, Вы писали:
W>А вот встречный вопрос: владея примитивами compose/map/fold/filter/zip/cons я могу прекрасно (и достаточно компактно) решить встающие задачи (в т.ч. и те, что были указаны в топике — про графы, коллецкии и циклы) без применения linq, причем начиная с рамок .net 2.0. Стоит ли мне этот самый linq использовать или даже изучать? В чем профит (м.б., кроме расхода железных ресурсов), так сказать?
Гм. Если есть достойная реализация этих примитивов, то why бы и not? У linq есть то преимущество, что он есть в библиотеке классов фреймворка. Как говорится "лучший танк тот, который есть". У linq есть то преимущество что операции могут быть реализованы неким провайдером, который будет оптимизирован под конкретный источник.
Кстати, если у тебя есть ссылки на другие библиотеки, реализующие эти операции, то я с удовольствием их изучу.
Здравствуйте, Mazay, Вы писали:
VD>>Ну, так появись. Или хотя бы почитай что-то прежде чем обсуждать то в чем ты вообще ничего не понимашь. VD>>Твои рассуждения о линке выглядят как полная чушь для тех понимает что это такое.
M>Да что ты говоришь?! А то я не понимаю.
Уместнее говорить о том, что ты понимаешь. Из твоих слов ясно одно. Про линк ты слышал где-то, что-то слышал, но разобраться в вопрос что это, как работает и для чего нужно так и не удосужился. Цитирую тебя:
оттуда их можно спокойно выдернуть SQL запросом, который отработает на сервере, который всё соптимизирует, закэширует и т. д. Зачем мне самому держать коллекции, к которым потом обращаться через заново изобретенный SQL и не забывать синхронизировать с базой?
Разберем эту цитату...
Начнем с того, что линк бывает разный, но если говорить об взаимодействии с СУБД через LINQ to SQL, LINQ to BLToolkit или даже через LINQ to Entety провайдеры, то никаких коллекций нигде держать не приходится. Линк-провайдер формирует SQL. Этот SQL выполняется на сервере (в СУБД). Обратно возвращаются только результаты запросов. Ничего синхронизировать не нужно. То что возвращенные данные преобразуются в объекты еще не значит, что это какой-то кэш. Если выполнить SQL-запрос, то мы тоже получим некоторые данные. Так вот эти объекты это и есть эти данные, только автоматически помещенные в объекты.
M>Если бы я понимал в чём цимес Линк, то наверное не писал бы сюда.
Да уж. Ну, или писал что-то более похожее на правду. Почти уверен, что и мнение было бы полностью противоположенным.
M> Я вообще-то надеялся на диалог с адекватными РСДНерами не на обсирание тобой.
Ты меня извини, но ты сам себя подставил когда начал нести околесицу по вопросу в котором некомпетентен. Меня просто возмутила та уверенность с которой ты озвучил свои домыслы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Wolverrum, Вы писали:
W>А вот встречный вопрос: владея примитивами compose/map/fold/filter/zip/cons я могу прекрасно (и достаточно компактно) решить встающие задачи (в т.ч. и те, что были указаны в топике — про графы, коллецкии и циклы) без применения linq, причем начиная с рамок .net 2.0. Стоит ли мне этот самый linq использовать или даже изучать? В чем профит (м.б., кроме расхода железных ресурсов), так сказать?
Отвечу так. Я в последнее время в основном программирую на Nemerle. В библиотеках этого языка есть все перечисленные методы. Но тем не менее периодически я использую линк, так как шире чем приведенный набор. По сути линк — это завернутый в обертку методов prelud Haskell-я. Думаю, это само по себе объясняет полноту библоитек.
Кроме того многие функции в линке сделаны просто удобнее. Те же функции сортировки куда удобнее нежели те что принимают функции или объекты компараторы.
В общем, это добротно спроектированная библиотека дающая широкий набор примитивов.
ЗЫ
В прочем, в этой теме обсуждался не LINQ to Object, а скорее БД-провайдеры.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Temoto, Вы писали:
T>А вы можете провести чёткую грань между функциональным и декларативным программированием?
Это независимые вещи, с совсем разными определениями.
Функциональное — с использованием первоклассных функций.
Декларативное — с описанием что надо получить, вместо того, как это получать.
Одно не подразумевает другого, хоть и способствует.
Можно писать декларативно, но не функционально (SQL).
Можно писать функционально, но не декларативно (лямбда-исчисление).
T>>А вы можете провести чёткую грань между функциональным и декларативным программированием?
DM>Это независимые вещи, с совсем разными определениями. DM>Функциональное — с использованием первоклассных функций. DM>Декларативное — с описанием что надо получить, вместо того, как это получать. DM>Одно не подразумевает другого, хоть и способствует. DM>Можно писать декларативно, но не функционально (SQL). DM>Можно писать функционально, но не декларативно (лямбда-исчисление).
Здравствуйте, Temoto, Вы писали:
VD>>Мое мнение такое... Линк не очень хорош (во многих отношениях), но подан он очень даже хорошо. Это первая, реально успешная попытка преподнести массам функциональное программирование. Другие попытки провалились полностью.
T>SQL провалился?
SQL — это язык запросов к СУБД. Мы же говорим о программировании на языках общего назначения.
Кстати, если кто-то из читающих эту тему не был в отросли в 90-ые годы прошлого века, то поверьте на слово путь к SQL был очень не простым и многие воспринимали его в штыки или попросту не понимали зачем он нужен. Прошло 10 лет прежде чем программисты стали воспринимать SQL как что-то само собой разумеющееся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Мое мнение такое... Линк не очень хорош (во многих отношениях), но подан он очень даже хорошо. Это первая, реально успешная попытка преподнести массам функциональное программирование. Другие попытки провалились полностью.
T>>SQL провалился?
VD>SQL — это язык запросов к СУБД. Мы же говорим о программировании на языках общего назначения.
На мой взгляд, LINQ (а тема форума именно о нём, а не о прог-нии на языках общего назначения в целом) не менее специфичен (в плане решаемых задач), чем SQL.
Разве это плохо — сказать, что LINQ — вторая после SQL успешная попытка преподнести функциональное/декларативное программирование массам? Это обязательно опровергать?
VD>Кстати, если кто-то из читающих эту тему не был в отросли в 90-ые годы прошлого века, то поверьте на слово путь к SQL был очень не простым и многие воспринимали его в штыки или попросту не понимали зачем он нужен. Прошло 10 лет прежде чем программисты стали воспринимать SQL как что-то само собой разумеющееся.
Здравствуйте, Temoto, Вы писали:
T>На мой взгляд, LINQ (а тема форума именно о нём, а не о прог-нии на языках общего назначения в целом) не менее специфичен (в плане решаемых задач), чем SQL.
Ну, так это проблема взгляда.
1. Линк — это расширение ЯПОН (языка программирования общего назначения) вводящее в него поддержку ФП.
2. Линк + рекурсия (поддержка которой уже есть в ЯПОН) является достаточным для написания алгоритмов (полон по тюрингу).
T>Разве это плохо — сказать, что LINQ — вторая после SQL успешная попытка преподнести функциональное/декларативное программирование массам? Это обязательно опровергать?
Это не верно. А то что не верно, оно и не плохо, и не хорошо. Главное чего нет в SQL — это возможности формировать функции. Такие расширения есть в разных языках, но они не стандартны и не применимы внутри запросов.
В общем, SQL — это не язык общего назначения. И от того его нельзя рассматривать как пример превнесения ФП в массы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IT, Вы писали:
IT>>Как ни подавай, а чтобы оценить технологию, нужно в ней разобраться. А подавляющее большинство у нас устойчиво путает Linq с query comprehension. Хоть апподавайся — без толку.
VD>Дык в терменологической путаннице виноват МС. Нефига было называть целую груду разной всячины одним именем.
еще, наверное, стоило бы разделять синтаксис и саму бибилиотеку.
вот уже который спор вижу по-поводу LINQ, и всегда упор делается на обработку последовательностей и обсуждение вокруг LINQ-2-провайдер.
Но ведь синтаксис LINQ можно использовать с любым типом, например, отложенное выполнение:
using System;
namespace LinqOperation
{
internal class Program
{
private static void Main()
{
var serviceOne = new ServiceOne();
var serviceTwo = new ServiceTwo();
var op = from str in serviceOne.Load(42)
from ent in serviceTwo.Load("test")
select ent.Name + str;
// this could be transaction scope, for example
using (var context = new OperationContext())
{
Console.WriteLine(op.Execute(context));
}
}
}
public class OperationContext : IDisposable
{
public void Dispose()
{
}
}
public class NamedEntity
{
public string Name { get; set; }
}
public class ServiceOne
{
public Operation<string> Load(int id)
{
return Operation.Create(() => id.ToString());
}
}
public class ServiceTwo
{
public Operation<NamedEntity> Load(string name)
{
return Operation.Create(() => new NamedEntity { Name = name });
}
}
/// <summary>
/// Deffered operation.
/// </summary>
public class Operation<T>
{
internal Func<T> Process { get; set; }
public T Execute(OperationContext context)
{
return Process();
}
}
public static class Operation
{
public static Operation<T> Create<T>(Func<T> process)
{
return new Operation<T> {Process = process};
}
public static Operation<TResult> Select<TSource, TResult>(
this Operation<TSource> source, Func<TSource, TResult> result)
{
return new Operation<TResult>
{
Process = () => result(source.Process())
};
}
public static Operation<TResult> SelectMany<TSource, TInner, TResult>(
this Operation<TSource> source,
Func<TSource, Operation<TInner>> selecor,
Func<TSource, TInner, TResult> result)
{
return new Operation<TResult>
{
Process =
() =>
{
var src = source.Process();
return result(src, selecor(src).Process());
}
};
}
}
}
Здравствуйте, Lloyd, Вы писали:
L>Это же очевидно: меньше информации выражено явно => сложнее разбираться.
Не очевидно. Венгерская нотация, на мой взгляд, ухудшает читаемость программ.
Тип переменной должен быть понятен из названия и контекста использования, а дублирование информации только захламляет код.
Например
Dictionary<string, EntityData> nameToEntityData = new Dictionary<string, EntityData>();
воспринимается хуже чем
var nameToEntityData = new Dictionary<string, EntityData>();
Здравствуйте, 0x7be, Вы писали:
0>Кстати, если у тебя есть ссылки на другие библиотеки, реализующие эти операции, то я с удовольствием их изучу.
Есть, разве что, ссылка на свой самопал
VD>оттуда их можно спокойно выдернуть SQL запросом, который отработает на сервере, который всё соптимизирует, закэширует и т. д. Зачем мне самому держать коллекции, к которым потом обращаться через заново изобретенный SQL и не забывать синхронизировать с базой?
VD>Разберем эту цитату... VD>Начнем с того, что линк бывает разный, но если говорить об взаимодействии с СУБД через LINQ to SQL, LINQ to BLToolkit или даже через LINQ to Entety провайдеры, то никаких коллекций нигде держать не приходится. Линк-провайдер формирует SQL. Этот SQL выполняется на сервере (в СУБД). Обратно возвращаются только результаты запросов. Ничего синхронизировать не нужно. То что возвращенные данные преобразуются в объекты еще не значит, что это какой-то кэш. Если выполнить SQL-запрос, то мы тоже получим некоторые данные. Так вот эти объекты это и есть эти данные, только автоматически помещенные в объекты.
Я так понимаю, вопрос синхронизации с базой возникает, когда мы начинаем эти полученные объекты менять и хотим, чтобы данные менялись в базе. И тут у линка не все гладко.
Если нам не помогут, то мы тоже никого не пощадим.
