О достоинствах многословия и недостатках выразительности

Ява слишком многословна! Кто не наткнулся на такую ​​напыщенную речь в Интернете ранее? И парень хвастается [Вставьте выразительный язык туда], который вскоре заменит Java, потому что он гораздо более краткий: он может заменить эти 10 строк кода Java однострочными. Ах, сила!

К сожалению, для того, чтобы соотнести краткость с властью (и многословие с отсутствием силы), эти люди используют множество ярлыков, которые когда-то рассматриваются, вообще не имеют смысла. Эта статья направлена ​​на хирургическую деконструкцию таких ярлыков, чтобы выявить их недостатки. И потому что мне нравятся фактические дебаты — и потому, что в Интернете есть не только тролли, этот пост будет связан с другой точкой зрения Энди Петреллы .

Многословно не плохо

Наличие большего количества данных, чем необходимо, предотвращает повреждение сообщений при косвенной связи. Вот два простых, но точных примера:

• В сетевом проектировании есть понятие DBIt или Бит подтверждения доставки. Это просто сводка всех 0 или 1 текущей последовательности и гарантирует, что доставленный пакет был передан правильно, несмотря на неадекватное качество сети.
• В реальной жизни банковские счета имеют двухзначный контрольный ключ (по крайней мере, в большинстве европейских стран, о которых я знаю). Точно так же следует избегать зачисления средств на ошибочный счет.

То же самое для «многословных» языков; это уменьшает вероятность понимания ошибок.

Более кратким не является (обязательно) лучше

Говоря о том, что одна строка лучше, чем 10 строк, означает, что чем короче, тем лучше: к сожалению, это не так.

Давайте возьмем структуру кода, обычно встречающуюся в Java:

public List<Product> getValidProducts(List<Product> products) {
 
    List<Product> validProducts = new ArrayList<Product>();
 
    for (Product product : products) {
 
        if (product.isValid()) {
 
            validProducts.add(product);
        }
    }
 
    return validProducts;
}

В этом случае у нас есть список Productи мы хотим отфильтровать недействительные.

Простой способ уменьшить многословие — установить все в одну строку:

public List<Product> getValidProducts(List<Product> products) { List<Product> validProducts = new ArrayList<Product>(); for (Product product : products) { if (product.isValid()) { validProducts.add(product); } } return validProducts;}

Не достаточно кратко? Давайте переименуем наши переменные и метод obfuscated-style:

public List<Product> g(List<Product> s) { List<Product> v = new ArrayList<Product>(); for (Product p : s) { if (p.isValid()) { v.add(p); } } return v;}

Мы резко сократили детализацию нашего кода — и закодировали все в одну строку! Кто сказал, что Java слишком многословна?

Выразительность подразумевает неявность

Я уже писал ранее об опасностях неявности: те же аргументы могут быть использованы для программирования.

Давайте перепишем наш предыдущий фрагмент на Java 8 :

public List<Product> getValidProducts(List<Product> products) {
 
    return products.stream().filter(p -> p.isValid()).collect(Collectors.toList());
}

Гораздо лаконичнее и выразительнее. Но для этого требуется, чтобы
вы, я и все остальные (извините, я не устоял) хорошо знали API. То же самое касается
операторов Scala и так далее. И вот приходит мой старый друг, контекст:

• +Оператор известен практически всем на планете
• ++Оператор известен практически каждый разработчик программного обеспечения
• Оператор Элвиса, вероятно, известен разработчикам Groovy, но большинство программистов может довольно легко его запомнить.
• В то время как оператор: / ( aka foldLeft() ) требует знаний Scala и FP