IT>Этот топик как раз о том, что не у всех и я долго не мог понять почему

"Object-oriented programming is an exceptionally bad idea" (Edsger Dijkstra)

"I find OOP technically unsound" (Alex Stepanov, здесь)

"В каждой естественной науке заключено столько истины, сколько в ней математики" (Иммануил Кант)

var percents = 
                from percent in
                    from prov in
                        from p in providingVolumes
                        group p by p.Provider into pg
                        let total = pg.Sum(v => v.Volume)
                        from pp in pg
                        select new { pp, total }
                    join rec in
                        from r in receivingVolumes
                        group r by r.Account into rg
                        let total = rg.Sum(v => v.Volume)
                        from rr in rg
                        select new { rr, total }
                    on prov.pp.Account equals rec.rr.Account
                    select new Percent
                    {
                        Provider = prov.pp.Provider,
                        Receiver = rec.rr.Receiver,
                        Account  = prov.pp.Account,
                        Value    = prov.pp.Volume / prov.total * rec.rr.Volume / rec.total
                    }
                group percent by percent.Provider;

IT>>Казалось бы, причём тут Немерле? А вы думали я о чём? Не дождётесь!

Из Лингвы:

AVK>Не смог. Ответить, в смысле . Пишу и то и другое одновременно.

AVK>Я так понимаю, это обещаное объяснение, почему мне не нравится Немерле? Тогда мимо. Я как раз таки очень положительно отношусь к ФП, и даже первый готов воткнуть Хейлсбергу вилку в глаз за то, что в шарпе до сих пор нет паттерн матчинга .

Гоги, ты чей друг? Мой или медведя?

MK>Вот, кстати, очень интересный вопрос! Сколько смотрю на последние "жаркие" темы — учебный флейм и эту — всё пытаюсь представить, как же делать на ФП пользовательский интерфейс. Я пока что на ФП не пробовал ниче писать и вопрос скорее оффтопный, но мож кто чиркнет в общих чертах Вот как баттон на форму впихнуть?

module Main where
import Graphics.UI.WX

main :: IO ()
main
  = start hello

hello :: IO ()
hello
  = do f    <- frame    [text := "Hello!"]
       quit <- button f [text := "Quit", on command := close f]
       set f [layout := widget quit]

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data

AF>Любой интерфейс должен иметь состояние — просто потому, что пользователь так устроен Так что делать его в идеологии ФП — все равно что бегать в ластах.

    appWindow :: CompCircuit Window () (() :& QuitReq)
    appWindow = proc () -> do
        () :& Destruction := destruction
            <- unit (ordinaryWindow windowContent) -< () :& Title := constant "Accumulation demo"
        returnA -< () :& QuitReq := destruction

Много ли у нас обсуждений на тему жизни внутри метода? А чему у нас учат в вузах? Есть ли у нас хотя бы один предмет, рассказывающий как правильно писать код внутри метода? Скорее всего нет. А о чём там рассказывать? Вот и получается на уровне кода бескультурье, самопал и дурь. Но ведь это просто чудовищная несправедливость. Без кода внутри метода, без кодера программа работать не будет, точнее её просто не будет. Без внешней обвязки и архитектора хоть как-то, но можно обойтись.

void serialize(Archive& ar)
{
    ar & m_foo;
    ar & m_bar;
    ar & m_buz;
}

var obj = CreateDamnObject();
obj.ShitHappens = function () {
    if (obj.state == really_mean_it)
        ReportError("Oops!");
};

"Снаружи" методов у нас все шоколадно. Иерархии классов, сплошное ООП, полиморфизм и прочие извращения. "Внутри" методов — пещерный век.

class Item 
{
    Item Next;
}

КЛ>плюс от к захвату контекста все-же лучше прибегать с осторожностью.

_FRВынося метод "наружу" ты позваляешь кому-то (а как ты запрещаешь? ага, никак!) к нему обратиться, тем самым увеличивая связаность. К лишней связаности надо относиться с ещё большим подозрением чем "к захвату контекста". Кстати, из за чего требуется осторожность? И, между прочим, мы же говорим о методах, не захватывающих контекст.

КЛ>>связанность и там и там. только в одном случае по параметрам, в другом по локальным переменным. Наружу это куда? Я же написал — private.

    abstract class MyBaseCollection<T>
    {
        protected List<T> collection = new List<T>();

        public void Insert(T item)
        {
            collection.Add(item);
        }

        public abstract void Sort();
    }

    class MyConcreteCollection<T> : MyBaseCollection<T>
    {
        public override void Sort()
        {
            collection.Sort();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyBaseCollection<int> coll = new MyConcreteCollection<int>();
            coll.Insert(3);
            coll.Insert(2);
            coll.Insert(1);

            coll.Sort();
        }
    }

    class MyCollection<T>
    {
        List<T> collection = new List<T>();

        public void Insert(T item)
        {
            collection.Add(item);
        }

        public void Sort(Func<List<T>, List<T>> sortFunc)
        {
            collection = sortFunc(collection);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyCollection<int> coll = new MyCollection<int>();
            coll.Insert(3);
            coll.Insert(2);
            coll.Insert(1);

            coll.Sort(l => { l.Sort(); return l; });
        }
    }

MyMotionCompensationAlgorithm(mySomeData : SomeData, findSimilarBlock : Block * Block -> bool) : ResultData
{
  ...
  if (findSimilarBlock(block1, block2)) DoSomeWith(block1) else DoSomeWith(block2)
  ...
}

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

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

сout << "3.1415926...";

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

bra_ket u v =
      sum_product u (map coupled v)

add_matrices :: (Num a) => t -> t1 -> [[a]] -> [[a]] -> [[a]]
add_matrices _ _ = matrix_zipWith (+) where
       matrix_zipWith f a b = [zipWith f ak bk | (ak,bk) <- zip a b]

transposed a
    | null (head a) = []
    | otherwise = ([head mi| mi <- a])
                  :transposed ([tail mi| mi <- a])

scalar_matrix alpha a =
       [[alpha*aij| aij <- ai] | ai<-a]

matrix_matrix a b
       | null a = []
       | otherwise = ([sum_product (head a) bi | bi <- b])
                  : matrix_matrix (tail a) b

matrix_ket a v = [sum_product ai v| ai <- a]

bra_matrix v a = [bra_ket v ai | ai <- a]

bra_matrix_ket u a v = bra_ket u (matrix_ket a v)

orthogonals :: (Scalar a, Fractional a) => [a] -> [[a]]
orthogonals x =
      orth [x] size (next (-1))
      where
          orth a n m
              | n == 1        = drop 1 (reverse a)
              | otherwise     = orth ((gram_schmidt a u ):a) (n-1) (next m)
              where
                  u = unit_vector m size
          size = length x
          next i = if (i+1) == k then (i+2) else (i+1)
          k = length (takeWhile (== 0) x)

gram_schmidt :: (Scalar a, Fractional a) => [[a]] -> [a] -> [a]
gram_schmidt a u =
      gram_schmidt' a u u
      where
          gram_schmidt' [] _ w = w
          gram_schmidt' (b:bs) v w
              | all (== 0) b = gram_schmidt' bs v w
              | otherwise    = gram_schmidt' bs v w'
              where
                  w' = vectorCombination w (-(bra_ket b v)/(bra_ket b b)) b
          vectorCombination x c y
              | null x = []
              | null y = []
              | otherwise = (head x + c * (head y))
                            : (vectorCombination (tail x) c (tail y))

one_ket_triangle a b
    | null a = []
    | otherwise = (p,q):(one_ket_triangle a' b')
    where
        p    = [bra_ket u ak | ak <- a]
        q    = bra_ket u b
        a'   = [[bra_ket ck ai | ck <- orth] | ai <- v]
        b'   = [ bra_ket ck b  | ck <- orth]
        orth = orthogonals u
        u    = head a
        v    = tail a
        
one_ket_solution :: (Fractional a, Scalar a) => [[a]] -> [a] -> [a]
one_ket_solution a b =
    solve' (unzip (reverse (one_ket_triangle a b))) []
    where
        solve' (d, c) xs
            | null d  = xs
            | otherwise = solve' ((tail d), (tail c)) (x:xs)
            where
                x = (head c - (sum_product (tail u) xs))/(head u)
                u = head d

one_ket_triangle :: (Scalar a, Fractional a) => [[a]] -> [a] -> [([a],a)]
one_ket_triangle a b
    --
    -- Список пар (p, q) представляет собой
    -- строки треугольной матрицы P и вектора-столбца q
    -- в уравнении P x = q, которое было
    -- получено через линейное преобразование
    -- оригинального уравнения A x = b
    --
    | null a = []
    | otherwise = (p,q):(one_ket_triangle a' b')
    where
        p    = [bra_ket u ak | ak <- a]
        q    = bra_ket u b
        a'   = [[bra_ket ck ai | ck <- orth] | ai <- v]
        b'   = [ bra_ket ck b  | ck <- orth]
        orth = orthogonals u
        u    = head a
        v    = tail a