Я как-то нейтрально отношусь ко всем этим синтаксическим изыскам. На Java 1.8 вполне комфортно, Stream API или Time API были действительно существенным улучшением. Всё равно до C# ещё очень далеко в плане всей этой синтаксической жести. Когда писал на C# я конечно всем этим пользовался, но не могу сказать, что в Java очень скучаю по этому.

Мне вообще из языков больше всего нравится Lisp. Для Java и C# это недостижимый идеал. И, как это не удивительно, нравится JavaScript, потому что он духом напоминает Lisp. Какие-то извращенцы любители C#/Java/... придумали TypeScript, который нивелирует многие преимущества JavaScript. Ещё нравится Isabelle HOL, там фактически в каждой теории можно создавать свой язык со своим синтаксисом. А в Java/C#/... все эти синтаксические фишечки на мой взгляд особой погоды не делают.

mayton,

к сожалению только Lisp как идея, потому что в коммерческой разработке я его никогда не использовал. Common Lisp слишком большой и там много странных вещей. Scheme нравится больше, он более компактный, но не нравятся гигиенические макросы (define-syntax и т.п.) или я их не понимаю, это кажется усложнением. Наверное больше всего нравится Arc, но он вообще нигде не используется. Clojure и Racket выглядят интересно, но их толком не смотрел. Конечно у меня есть и своя реализация Lisp :) По смыслу она похожа на Arc. В качестве среды разработки, файлового менеджера, NNTP-клиента, браузера и т.п. у меня был конечно Emacs, а в качестве оконного менеджера Sawfish.

Мне в лиспе нравится минимализм, что в него не пытаются запихать всё, что только возможно. Всякие синтаксические вещи, проверки типов и т.п. добавляются самими программистами. Не нужно бороться с синтаксисом языка, ждать 10 лет, когда в него подвезут какой-нибудь pattern-matching. Придумывать всякие костыли, чтобы на этапе компиляции обойти ограничения языка или наоборот добавить какую-то логику (как только люди не исхищряются с template в C++). Мне когда-то очень давно нравился C++, потом я прочитал книгу Александреску, его Loki мне казалась чем-то очень клевым. А потом я познакомился с другими языками и понял, что всё это просто борьба с ограничениями языка.

В итоге я пришёл к тому, что чем меньше всей этой фигни в языке (разные синтаксические конструкции, статическая типизация и т.п.), тем лучше. В JavaScript как-раз всего этого нет и код писать проще. Если где-то нужны проверки, то можно просто определить какую-нибудь функцию assert или несколько её вариантов для разных случаев и добавлять где требуется. Либо ошибки должны выявляться анализаторами кода. Хотя я не могу сказать, что и статическая типизация - абсолютное зло. Но просто если не получается сделать какую-нибудь специфическую иерархию классов с generic'ами и т.п., то и фиг с ней, можно и в рантайме проверять что требуется.

Ещё одна идея, которая мне нравится в лиспе - это отношение к написанию кода как к созданию своего DSL. Скажем, у меня приложение работает с моделями. Для лиспа естественно определить несколько примитивных методов для запросов к этим моделям, для изменения моделей. На основе простейших функций определить более сложные и т.д. В итоге получится внутренне API, минифреймвок для работы с моделями. И всё приложение состоит из таких микрофреймвоков. Это звучит вроде совершенно логично. Но, блин, большинство Java- и других разработчиков, с которыми я сталкиваюсь, пишут код совершенно иначе. Обычно это какой-нибудь класс с кучей полей. В одном методе устанавливаем одно поле, потом вызываем другой метод, в котором читаем это поле и устанавливаем ещё какие-то поля. Сами методы - это куча вложенных циклов, if-ов. Полная каша, в которой вообще ничего невозможно понять. Если капнуть, то оказывается, что эти поля вообще не нужны (потому что они используются просто для передачи данных между методами, а не для хранения долговременного состояния объекта), все эти безумные вложенные циклы можно разбить на несколько повторно используемых методов.

В общем что нравится:
1) Минимализм, пусть лучше в языке вообще ничего не будет, чем ждать какой-нибудь очередной синтаксический сахар годами. Например, в JavaScript нет ни Stream API, ни LINQ, но есть итераторы и этого достаточно, чтобы сделать своё Stream API. Или без классов вполне как-то обходились
2) Отношению к языку не как к данности, что если что-то нельзя написать, значит это что-то неправильное. Может просто язык стрёмный
3) Построение кода из небольших самостоятельных блоков (микро-DSL, микрофреймвоков, внутренних API). Люди, которые ни на чём кроме Java не писали, либо впадают в ступор, когда чего-то нет в стандартной библиотеке, либо пишут какой-то лапшакод
4) Конечно же уникальная штука - это макросы. В других языках это решается костылями в виде препроцессоров, шаблонов, рефлексии, аннотаций, кодогенерации, добавления синтаксического мусора, систем типов, а в лиспе всё это закрывается одной конструкцией

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

Например вот:

1) Есть модель . В виде XML-файла она выглядит страшно, но по сути это просто диаграмма классов с наследованием, атрибутами, связями между классами.

2) Из этой модели они сгенерили тонны Java-классов и интерфейсов.

3) В том числе сгенерили и такой класс . Да, в нём куча switch/case и if, но какая разница, сопровождать его всё равно не нужно. Если изменится модель, то все эти классы они просто перегенерят. Причём сейчас этот класс можно сгенерить с паттерн-мэтчингом вместо if. Достаточно чуток изменить шаблон кода и нажать кнопку.

4) Затем мы просто наследуемся от этого сгенеренного класса и переопределяем нужные case-методы.


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

Хотя, блин, на самом деле здесь не совсем visitor, а просто switch. И благодаря паттерн-матчингу этот Switch-класс больше не нужен, сейчас действительно этот код можно писать проще, хотя благодаря кодогенерации люди и раньше не особо напрягались, но сейчас и кодогенерация не нужна. Но если нам нужен не просто switch, а более сложный visitor, который рекурсивно обходит дерево, т.е. смотрит какие у объекта вложенные объекты, переходит к ним и так далее, то здесь кодогенерация может и пригодиться, а на голом паттерн-матчинге запаришься писать столько кода.

Опять-таки, возвращаясь к лиспу, там вообще таких проблем нет. Не нужно ни ждать много лет паттерн-матчинга, ни генерить код, всё решается макросами. А в Java остаётся либо мучаться и ждать, либо просто генерить нужный код.

mayton,

я думаю, что подавляющее большинство JavaScript-библиотек - это просто ужас. Есть исключения типа d3, она построена на одной понятной идее и всё вокруг неё крутится.

Вопрос нужны ли для JavaScript вообще какие-то фреймвоки. HTML, CSS, SVG и стандартные API (WebGL, ...) позволяют делать крутейшие вещи, которые на каком-нибудь SWT запаришься делать. На мой взгляд, приложение в принципе должно состоять из микрофреймвоков. Если нет хороших готовых, то остаётся писать свои. Правда нет гарантии, что получится лучше :)

mayton,

я не могу показать код из-за NDA, но там эпичные вещи. Эпичные вещи долго описывать. Приведу такой пример (псевдокод):




Ни selection, ни getName() нигде больше не используются. getName() однозначно не потребуется переопределять в дочерних классах, да, и дочерних классов тоже быть не должно.

Зачем это поле? Зачем этот метод? Если так уж хочется сделать метод, то почему бы не передавать туда selection как аргумент? Ну, тут ещё ладно, глядя на этот код можно понять о чём он. Но когда таких полей и методов десятки, то вообще ничего не понять. Для начала что-нибудь такое (поля/методы желательно перемешать, чтобы было непонятно что в какой очередности вызывается, где и зачем используется):




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

Да! А в лиспе ленивость добавляется макросами, если нужна.