Ну вот логично было бы разрешить var только для случая использования анонимных типов и только для него.

>В итоге, с точки зрения программиста (а, значит, с точки зрения абстракции) это будет одно и то же

Вот не уверен. В яве (то что будет в 8-ке)

Comparator pointComparator = { Point p1, Point p2 -> p1.getX().compareTo(p2.getX()) };

pointComparator будет типа Comparator и вставить его вместо, скажем, какого нибудь интерфейса DistanceFinder c той же сигнатурой вы не сможете.
Что хорошо, т.к. повышает типобезопасность.

Прочитал. Но не убедился. Инкапсуляция, конечно, хорошо, но использовать var ради идеи инкапсуляции — это, имхо, перебор. Тогда логичнее уж использовать

SomeInterface obj = ...

Инкапсуляция тоже будет в полной мере соблюдена без ущерба для понимаемости кода.

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

(имхо)

Ок, уменьшили

catpad.net/michael/apl/

Понятнее стало?

Думаю, он имел в виду другое, например, уровни абстракции.

Ну тут можно конечно поспорить о том, что классы обычно дизайнят более продвинутые разработчики, чем те, которые их используют. Но всё-равно, лично я не понимаю, зачем скрывать детали. Ведь, как завещал Гвидо ван Россум, explicit is better then implicit.

Ну в яве тоже скоро будет FP (project lambda). Но даже там не будет никаких делегатов как отдельных сущностей. По сути, это будет просто краткая форма записи inner classes, т.е. тип лямбды будет равен SAM(Single Abstract Method)-типу на месте которого она была использована, хотя и с оптимизациями, основанными на invokedynamic. Хотя для прикладного программиста будет выглядеть и работать именно как сокращенная форма синтаксиса.

>зачем вам нужно знать _тип_, если для чтения кода достаточно знать _роль_ объекта

Возвращаясь к примеру

var obj = doSmthUseful(arg1, arg2, arg3);

Я так понимаю, читая унаследованный код, роль мы должны узнать из имени (в данном случае doSmthUseful)?
Теперь вопрос: а где гарантия что предыдущие авторы кода были достаточно сознательный для того чтоб придумать адекватное имя методу, которое бы объясняло бизнес-роль объекта obj?

>Но сами же протестуете против нее. предлагая вводить конкретный класс Operation вместо обобщенного Func.

Это не я протестую. Это Вы неправильно трактуете смысл слова «однородность». По Вашей логике — чем больше классов в коде программы тем её код более неоднороден? Согласитесь, это абсурд. Наоборот, в яве мы имеем все те же plain old objects, а в шарпе имеем некую новую сущность под названием «делегат».

Да. Я просто пытаюсь сказать, что по моему скромному мнению, однородность куда важнее выразительности (в стратегическом плане).

>И тем беднее (менее выразительно).

Глядите какой выразительный и богатый код:
www.cpan.org/misc/japh
ru.wikipedia.org/wiki/JAPH

Это к тому что богатство возможностей не всегда плюс.

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

Складывать яблоки с кирпичами? Нет уж, спасибо.

>это несколько многословно

Зато более понятно. Хороший код должен быть удобен для чтения, в первую очередь, и лишь во вторую для написания. С написанием кода тоже проблем нет при текущем развитии IDE.

Не кажется. Имхо, явный тип Operation кажется куда нагляднее загадочной сигнатуры Func<double, double, double>.

Плюсую, слава богу, в яве не додумались так сделать.

Java-вариант, и без всяких делегатов. Имхо, ява попроще (в хорошем смысле) в этом случае.

package tests;

import java.util.HashMap;
import java.util.Map;

public class Calc {
    private Map<String, Operation> operations = new HashMap<>();

    static abstract class Operation {
        private String op;

        public Operation(String op) {
            this.op = op;
        }

        abstract int perform(int a, int b);
    }

    public static void main(String[] args) {
        Calc calc = new Calc()
                .addOperation(new Operation("+") {
                    @Override
                    int perform(int a, int b) {
                        return a + b;
                    }
                })
                .addOperation(new Operation("*") {
                    @Override
                    int perform(int a, int b) {
                        return a * b;
                    }
                });

        System.out.println(calc.perform("+", 2, 5));
        System.out.println(calc.perform("*", 2, 5));
    }

    private Calc addOperation(Operation operation) {
        operations.put(operation.op, operation);
        return this;
    }

    public int perform(String op, int a, int b) {
        return operations.get(op).perform(a, b);
    }
}

Ну вот, моё мнение что структуры повышают издержки программиста на проектирование, причины я описал выше (каждый раз надо думать, что правильнее использовать и какие последствия это повлечет), и, возможно, понижают издержки на проц и память. Возможно, потому что при неправильном применении, например, частая передача через параметры (понятно, с полным копированием) может только все замедлить.

Издержек от программиста при написании программы или издержек процессора и памяти при её выполнении?

Получается, что не понял. Поясните, пожалуйста.

Зачем value objects нужно явно синтаксически отделять от не-value objects? Зачем мне при этом нужно думать и учитывать особенности поведения тех и других? Ради чего? Впрочем, Вы сами сказали «дешевый», что еще раз подтверждает мой тезис.

Зачем нужно использовать структуры, кроме как с точки зрения производительности?
Не логично ли, если (вообразим) разницы в производительности бы не было, использовать одну сущность (class) vs две (class/struct)?