Информация об изменениях

Сообщение Re[5]: Delphi и велосипедирование от 30.06.2024 14:06

Изменено 30.06.2024 15:51 Sinclair

Re[5]: Delphi и велосипедирование
Здравствуйте, akasoft, Вы писали:
A>Это называется "библиотечная поддержка".
Чтобы она появилась, потребовалась для начала поддержка в языке.
На K&R С вы не напишете ничего подобного filter/map/reduce никаким библиотечным способом.
A>За этими filter/map/reduce кто-то попердолился и скрываются кучи кода.
Хороший язык предоставляет пологую кривую трудозатрат/выигрыша. Простейшая реализация filter/map/reduce на более-менее любом современном языке никакой кучи кода не требует:
public static IEnumerable<T> Where<T>(IEnumerable<T> source, Predicate<T> predicate) 
{
  foreach(var item in source)
    if(predicate(item))
      yield return item
}
public static IEnumerable<R> Select<T, R>(IEnumerable<T> source, Func<T, R> selector) 
{
  foreach(var item in source)
      yield return selector(item)
}
public static A Reduce<T, A>(IEnumerable<T> source, Func<A, T, A> aggregate, A startValue)
{
  foreach(var item in source)
    startValue = aggregate(startValue, item);
  return startValue;
}

И только если нас не устраивает производительность вот такой универсальной реализации, мы захотим делать её специализации. И, опять же, хороший язык даст нам это сделать не ломая прикладной код.
То есть на том конце, где библиотека потребляется, код так и останется таким, как был:
var a = [4, 8, 15, 16, 23, 42];

var b = a.Where(e => e % 2 == 0).Select(e => e * 3).Reduce((a, e) => a * e % 13);

A>А уж написать это в строку или в столбик значения не имеет.

Значение имеет то, насколько легко пишется и читается такой код. Пример на Delphi читается ужасно, не правда ли?
Re[5]: Delphi и велосипедирование
Здравствуйте, akasoft, Вы писали:
A>Это называется "библиотечная поддержка".
Чтобы она появилась, потребовалась для начала поддержка в языке.
На K&R С вы не напишете ничего подобного filter/map/reduce никаким библиотечным способом.
A>За этими filter/map/reduce кто-то попердолился и скрываются кучи кода.
Хороший язык предоставляет пологую кривую трудозатрат/выигрыша. Простейшая реализация filter/map/reduce на более-менее любом современном языке никакой кучи кода не требует:
public static IEnumerable<T> Where<T>(IEnumerable<T> source, Predicate<T> predicate) 
{
  foreach(var item in source)
    if(predicate(item))
      yield return item
}
public static IEnumerable<R> Select<T, R>(IEnumerable<T> source, Func<T, R> selector) 
{
  foreach(var item in source)
      yield return selector(item)
}
public static A Reduce<T, A>(IEnumerable<T> source, Func<A, T, A> aggregate, A startValue)
{
  foreach(var item in source)
    startValue = aggregate(startValue, item);
  return startValue;
}

И только если нас не устраивает производительность вот такой универсальной реализации, мы захотим делать её специализации. И, опять же, хороший язык даст нам это сделать не ломая прикладной код.
То есть на том конце, где библиотека потребляется, код так и останется таким, как был:
var a = [4, 8, 15, 16, 23, 42];
var b = a.Where(e => e % 2 == 0).Select(e => e * 3).Reduce((a, e) => a * e % 13);


A>А уж написать это в строку или в столбик значения не имеет.

Значение имеет то, насколько легко пишется и читается такой код. Пример на Delphi читается ужасно, не правда ли?