и тем не менее в тех же плюсах
template [class F] // парсер — туды его в качель
auto g(F f) { return f(); }
void f() {}
g(f);
работает. return void в полный рост.

А как паскаль бьет по рукам за Pointer?

в идеале (то есть не обращая внимания на совместимость) и имея на уме not null reference из C# 8 имеет смысл такой синтаксис:

if (MyMethod() is var x) // x is not null
if (MyMethod() is var? x) // x can be null

Хм, я бы просто сделал PieChartService/BarChartService/LineChartService. Реализовал бы из используя Google Charts. Решил бы поменять фреймвок — ну поменял бы реализацию этих классов.

вот чем лучше: public LocalController([Dependency(«local»)] IService service)
по сравнению с public LocalController(LocalService service) ??

В первом случае мы закладываемся на какую то магическую строку, по которой обязательно должен быть создал локальный сервис(не просто так же в атрибуте строка «local» сидит). Во втором случае — такой зависимости нет. В чём прикол?

на низкоуровневом языке вроде Java или Objective-C.

Вы сделали мой день, спасибо -)

Массивы в FB есть http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-datatypes-bnrytypes.html#fblangref25-datatypes-array

гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд

насколько я понимаю, дженерики сделаны такими, потому чтобы новые бинарники воспринимались старыми JVM(правда это так и не получилось). котлин же явно декларирует, что новые бинари на старом рантайме работать не будут.
На счет устарелого дизайна коллекций и тд, в котлине есть такая фича, можно запретить использование deprecated метода в момент компиляции. То есть если через 10 JB решат, что fun mySuperPuperFunc() — это аццтой, то эту функцию они пометят @Deprecated(level = DeprecationLevel.Error) и новый код не сможет её больше юзать(не будет компилироваться). При этом старые бинари будут отлично работать. ИМХО нормальное решение

Один из конкурентов — ReactiveUI

public class ViewModel : ReactiveObject
{
	public ViewModel()
	{
		_fullName = this.WhenAny(x => x.FirstName, y => y.LastName, 
			(firstName, lastName) => firstName + " " + lastName)
			.ToProperty(this, x => x.FullName);
	}
	private string _firstName;
  	public string FirstName 
  	{
  		get { return _firstName; }
  		set { this.RaiseAndSetIfChanged(ref _firstName, value); }
  	}

  	private string _lastName;
	public string LastName 
  	{
  		get { return _lastName; }
  		set { this.RaiseAndSetIfChanged(ref _lastName, value); }
  	}

  	private ObservableAsPropertyHelper<string> _fullName;
  	public string FullName 
  	{
  		get { return _fullName.Value; }
  	}
}

К сожалению все эти Wrapper'ы не помогут сохранять примитивы в аттрибуты…

А возможности сравнивать схемы БД с генерацией диф скрипта нету ???

Это просто функция которая запускает лямбду (то что в фигурных скобках).
То есть можно написать так… = { /*тело лямбды*/ }()
но столько видов скобок подряд плохо читается. Поэтому используют функцию run.

А как же сопоставление образцу (pattern matching)?

Нету. Есть typecheck + auto typecast. Это увы не PM.

собственно чего это я, если к return совсем уж религиозная ненависть, то можно без него любой код писать:
fun calc(arg: Int): Int = run {
database.execute()
network.execute()
arg + 10
}

для однострочников в котлине return тоже необязателен.
fun max(a: Int, b: Int): Int = if (a > b) a else b

свой грид не нужен, достаточно к существуемому аттачед свойства нарисовать

Есть MVVM фреймворк, ориентированный на кроссплатформ: ReactiveUI. Любителям Rx — must have

reference to function (): ResultType — это не тип. Это синтаксическая конструкция для объявления типа. Соответсвенно именно так написать нельзя.
Другое дело, что можно было вместо своих алиасов использовать предопределенные TProc/TFunc

опечатки
было: for V in Data do Sum := Sqr(V — Mean);
стало: for V in Data do Sum := Sum + Sqr(V — Mean);

было: StdDev = Sqrt(Data.Map(v => Sqrt(v — Mean)) / Pred(Length(Data)));
стало: StdDev = Sqrt(Data.Map(v => Sqrt(v — Mean)).Reduce((a, b) => a + b) / Pred(Length(Data)));

Вообще забавно. Автор статьи для демонстрации силы лямбда(анонимных методов) использует стандартные функции для обработки коллекций. Собственно так делают во многих языках(C#, Java,C++). Вот только для дельфи выходит фейл. Вот как выглядит MeanAndStdDev в классическом стиле:

procedure MeanAndStdDev;
var
  Data: TArray<Double>;
  V, Sum, Mean, StdDev: Double;
begin 
  Data := [1, 1, 3, 5, 5];    

  Sum := 0;
  for V in Data do Sum := Sum + V;
  Mean := Sum / Length(Data);

  Sum := 0;
  for V in Data do Sum := Sqr(V - Mean);
  StdDev := Sqrt(Sum /  Pred(Length(Data)));

  WriteLn('Mean: ', Mean, ' StdDev: ', StdDev); // => Mean: 3.0 StdDev: 2.0  
end;

ИМХО гораздо читабельнее, чем в статье. Вообще не видно, зачем тут нужны лямбды.
А причина в чрезмерно раздутом синтаксисе. Предположим, что в дельфи был бы C#овских синтаксис лямбд:

Mean = Data.Reduce((a, b) => a + b); // даже не нужно описывать функцию Sum
StdDev = Sqrt(Data.Map(v => Sqrt(v - Mean)) / Pred(Length(Data)));

Получились однострочники. Вот тут видно, что лямбды могут сократить код, может имеет смысл что это за зверь.