U>Изучив весь этот материал, думаю можно будет и с VladD2'ом спорить в ФП

This is all a good idea, but I've found that I've never learned nearly
as much as when I started bashing out some code. So I highly recommend
starting up some project that's interesting to you too. (A. Wagner)

К>>насчёт Питона тож сомнения

Суть подхода состоит в том, что программа представляет собой не набор команд, а описание действий, которые необходимо осуществить.

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

id(X) -> X.

LCR>Так что закрывай браузер, и вперёд to bash out some code

Did you actually run the shell on your system? If not, please stop and try it now. If you just read the text without typing in the commands, you may think that you understand what is happening but you will not have transferred this knowledge from your brain to your fingertips — programming is not a spectator sport. Just like any form of athletics, you have to practise a lot.

...concurrent, functional, distributed...

К>насчёт Питона тож сомнения

Императивный подход имеет много общего с естественными языками, поэтому он достаточно понятен для понимания, и языки программирования базирующиеся на нем легче поддаются изучению.

Суть подхода состоит в том, что программа представляет собой не набор команд, а описание действий, которые необходимо осуществить.

Такой подход существенно проще и прозрачнее формализуется математическими средствами и, как следствие требует для понимания гораздо более высокую математическую подготовку.

Одним из путей развития декларативной парадигмы стал функциональный подход к программированию.

К сожалению данное семейство также не является чисто функциональным.

Поэтому нет смысла сравнивать эти подходы или противопоставлять, гораздо лучше их совместить

 "string".ToCharArray()

Есть два цвета — черный и белый,
Но есть оттенки, которых больше.
Мы, дети проходных дворов
Найдем сами свой цвет.

В. Цой

VD>Бред .

\f x -> x -- 0
\f x -> f x -- 1
\f x -> f (f x) -- 2
\f x -> f (f (f x)) -- 3

class A { public Prop1 : int { get{...} }
class B: A { public Prop2 : A { get{...} }

match (x)
{
  | B{ Prop1=1; Prop2=B { Prop1=2; }; } => ...
  | A{ Prop1=1; } => ...
}

VD>class A { public Prop1 : int { get{...} }
VD>class B: A { public Prop2 : A { get{...} }

VD>match (x)
VD>{
VD>  | B{ Prop1=1; Prop2=B { Prop1=2; }; } => ...
VD>  | A{ Prop1=1; } => ...
VD>}
VD>

type Forest a = [Tree a] 

data Tree a = Node {
                    rootLabel :: a 
                    subForest :: (Forest a) 
                   } 

drawTree :: Tree String -> String
drawTree  = unlines . draw

draw :: Tree String -> [String]
draw (Node x ts0) = x : drawSubTrees ts0
  where -- разбираем по конструкторам списка
        drawSubTrees []     = []
        drawSubTrees [t]    = "|" : shift "`- " "   " (draw t)
        drawSubTrees (t:ts) = "|" : shift "+- " "|  " (draw t) ++ drawSubTrees ts

        shift first other = zipWith (++) (first : repeat other)

drawTree (Node "r" [(Node "a" []), (Node "b" [])])

r
|
+- a
|
`- b

/// Описывает ветку дерева «красно-черного» дерева.
public variant Node[T] : IEnumerable[T] where T : IComparable[T] 
{
  | Red   { key : T; lchild : Node[T]; rchild : Node[T]; }
  | Black { key : T; lchild : Node[T]; rchild : Node[T]; }
  | Leaf

  /// Подсчет количества элементов.
  public Count : int 
  {
    get
    {
      match (this)
      {
        | Red(_, left, right) | Black(_, left, right) =>
          1 + left.Count + right.Count
        | _ => 0
      }
    }
  }

VD>>>class A { public Prop1 : int { get{...} }
VD>>>class B: A { public Prop2 : A { get{...} }

VD>>>match (x)
VD>>>{
VD>>>  | B{ Prop1=1; Prop2=B { Prop1=2; }; } => ...
VD>>>  | A{ Prop1=1; } => ...
VD>>>}
VD>>>

| B { Prop1=1; Prop2=B { Prop1=2; } as b; } => b.Prop2 *= 2;

| B { Prop1=1; Prop2=B { Prop1=x; }; } => x

VD>| B { Prop1=1; Prop2=B { Prop1=2; } as b; } => b.Prop2 *= 2;
VD>

VD>| B { Prop1=1; Prop2=B { Prop1=x; }; } => x
VD>

if (typeof(x)=B && x.Prop1=1 && typeof(x.Prop2)=B && x.Prop2.Prop1=2)
    {x.(добрались через "." до нужного свойства)*=2;}
else if (typeof(x)=A && x.Prop1=1)
    {...}

D>if (typeof(x)=B && x.Prop1=1 && typeof(x.Prop2)=B && x.Prop2.Prop1=2)
D>    {x.(добрались через "." до нужного свойства)*=2;}
D>else if (typeof(x)=A && x.Prop1=1)
D>    {...}
D>

D>Чуть длиннее, но ИМХО требования к x выражены более ясно

//  | B{ Prop1=1; Prop2=B { Prop1=2; }; } => ...
B b1 = x as B.
if (b1 != null && b1.Prop1 == 1)
{
  B b2 = b1.Prop2 as B;
    if (b2 != null && b2.Prop1 == 2)
    {
      ...
    }
}

top(v1,_).
top(_,v2).
top(_,_) :- top(v1,v2).

bottom(_,_) :- bottom(v1,v2).  % получили (_|_)
bottom(v1,_).
bottom(_,v2).

К>bottom(_,_) :- bottom(v1,v2).  % получили (_|_)
К>bottom(v1,_).
К>bottom(_,v2).
К>

XSB Version 2.2 (Tsingtao) of April 20, 2000
[x86-pc-windows; mode: optimal; engine: chat; scheduling: batched]
| ?- [bottom].
[Compiling .\bottom]
% Compiling predicate bottom/2 as a tabled predicate
[bottom compiled, cpu time used: 0.0310 seconds]
[bottom loaded]

yes
| ?- bottom(v1,v2).
yes

К>> Он что, выбирает наиболее подходящий образец (тогда это какой-то неправильный пролог)? Или как-то умеет распознавать задницу?

% встроенный предикат для зацикливания
repeat.
repeat :- repeat.

write_stars :- repeat, write('*'), fail.

% или более осмысленное

read_until_eof(C) :-
    read_char(C);
    read_until_eof(C). % здесь мемоизация не нужна

read_and_print :-
    read_until_eof(C), % рукодельный цикл repeat-fail
        write(C),
        fail;
    write("EOF!!!").