elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
The Road to Java.next
elizarov
В последнее время всё чаще обсуждается вопросы "Как должен развиваться языка Java?" и "Что придет на смену Java?". В качестве примеров т.н. Java.next языков приводятся Scala, Groovy и множество других экспериментальных и реальных языков. Изучение этих языков, в свою очередь, подпитывает желание добавить ту или иную фичу в Java. Наиболее конструктивная критика Java заключается в том, что для множества реальных задач приходится писать слишком много "boiler plate code". Например, всем известен такой шаблон:


InputStream in = openStream();
try {
    // ... do something with in.
} finally {
    in.close();
}


Многие хотели бы вместо этого куска когда писать что-то похожее на вот такой код (a la C#), преимущество которого особенно заметно при работе с несколькими ресурсами одновременно:

using (InputStream in : openStream()) {
    // ... do something with in.
}


И вот тут программисты делятся на два лагеря. Одни говорят: давайте добавим в язык Java "cильные" closures (например, по BGGA) и дадим возможность программистам самим менять синтаксис языка, то есть определять конструкции вроде "using" в соответствии с их project-specific потребностями. Другие говорят, что добавить closures это значит дать обезьяне в руки гранату. Читаемость кода существенно упадет из-за огромного количества специальных конструкций которые программисты создадут для своих целей. Давайте добавим конкретные расширения языка once-and-for-all аналогично указанному выше "using" и, тем самым, решим 90% самых острых проблем.

Похожая дискуссия разгорается и вокруг JavaBean properties и шаблонных методов getXXX и setXXX. Современные Java IDE умеют их генерировать (как и другие шаблоны), но пишем-то мы код один раз, а читаем потом десятки раз. Как же сделать Java код более читабельным? Нужно ли для этого добавлять в язык более универсальные или более простые, понятные и конкретные механизмы?

Кто прав? Как заранее узнать какое именно расширение языка принесет больше пользы, а какое принесет больше вреда?

Я не знаю ответа на эти вопросы, но я знаю путь который можно использовать для поиска ответов. На этот путь меня натолкнуло вот это обсуждение The Road to Java.next. Вкратце идея такова: вместо того, чтобы добавлять новые синтаксические конструкции в язык, давайте добавим их в наши IDE. Ничто не мешает современному IDE автоматически выявлять шаблоны кода и заменять их на более простые синтаксические конструкции исключительно на экране, в то время как в исходниках они будут оставаться в своем развернутом виде. Это позволит, например, пользоваться конструкцией using в любой версии Java и проверить её применимость на практике не внося необратимых изменений в сам язык Java.

Конечно, не любое потенциальное расширения языка поддается такому эксперименту. Речь идет об исключительно синтаксических конструкциях. Например, очень легко реализовать на уровне IDE т.н. CICE closures, чтобы вот этот код:

executor.submit(new Runnable() {
    public void run() {
        action();
    }
});


на экране вашего IDE выглядел бы как:

executor.submit(Runnable() {
    action();
});


В то время как BGGA closures не представляются как простая синтаксическая трансформация.

Но это лучше чем ничего, учитывая что синтаксические шаблоны и их эквивалентные замены могли бы втыкаться пользователем в конфигурацию IDE а также включаться и отключаться по желанию. Что по этому поводу думают программисты? Будет ли это полезно? А что думают люди которые работают над созданием Java IDE? Можно ли это реализовать?
Tags:

  • 1
С чем-то похожим наши пользователи ещё давным-давно экспериментировали: см. http://plugins.intellij.net/plugin/?id=57

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

Если бы это было совсем уж просто, то давно уже кто-нибудь бы сделал. Но мне кажется, что потенциальный выигрыш настолько велик, что стоит провести серьёзный brain-storming -- глядишь найдется какое-нибудь нетривиальное решение, которое станет еще одним конкурентным преимуществом вашего продукта. Сворачивание импортов, комментариев и блоков кода вы ведь осили. Сворачивание шаблонов кода это, конечно, более сложная задача, но она ведь идет в этой общей конве, особенно если начать с mutli-line шаблонов и не пытаться на первых порах сворачивать in-line шаблоны.

Так запросто на уровне IDE показывать один код, а хранить другой -
это и правда слишком трудно.

Однако можно сделать такой конкретный синтаксис, который будет позволять расширения, а без расширений совпадать с конкретным синтаксисом Java.

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

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

Сделать свой синтаксис это не чудо, и очень, очень многие именно так и поступает. Проблема только в том, что у такого подхода очень маленький "adoption rate". Я, например, не буду в своем production проекте экспериментировать с каким-то новым синтаксисом, а буду ждать пока он станет main-stream. Вот тебе проблема курицы и яйца. Если твой синтаксис действительно крут, то он рано или поздно полетит, но это займет очень много времени.

Да, через IDE это сложно, но и потенциальные преимущества огромны. Этим сразу смогут начать пользоваться все, а по мере использования выявлять те шаблоны, который действительно заслуживают включения в компилятор.

кто умеет программить, тот пишет и на асме и на Java 1.1 и на Java 1.6, а кто не умеет, требует навернуть язык, но это ума не прибавляет.. лично я считаю, что не стоит превращать язык в басню Михалкова "слон-живописец"

"write-only" код, конечно, все-равно на чем писать.

А я вот чаще читаю код, чем пишу. И я не хочу читать код на asm-е и мне хочется тратить меньше времени на продирание через шаблонный код. Язык Java я тоже портить не хочу, и именно поэтому мне намного больше нравится, чтобы распознаванием простых шаблонов занималось IDE.

Хорошая мысль.
Я бы даже согласился на сворачивание только тех шаблонов, что я лично определил и явно указал на их использование - и то код был бы читабельнее...
Да и реализовать такое несравненно легче.

Я бы тоже согласился, но хотел бы все-таки более общую конструкцию. А главное, из этой общей конструкции следует и частная. Если хочется чтобы она видела только специально помеченные шаблоны, то заведи аннотацию и помечай ей все свои экземпляры шаблона в коде. А в шаблон, который распознает IDE, добавь аннотацию как часть шаблона которому должен соответствовать код.

... Ах, как могли бы красиво в IDE выглядеть страницы методов getXXX и setXXX в бинах -- каждый свернут в одну строчку с какой-нибудь иконкой, названием шаблона (типа "readwrite property") и именем свойства. Зачем читать этот код, если ты знаешь что он соответствует шаблону и значит точно работает правильно? А все свойства, где идет специальная обработка, сразу бы "торчали напоказ".


О! Изобрели велосипед!

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

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

Во-во. А главное, что современные IDE уже почти там. Они уже научились контекстно-синтаксически подсвечивать код (по разному выделать переменные, методы и т.п.), научились синтаксически сворачивать, даже умеют искать код по шаблону. Надо только объединить это всё вместе.

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

Не совсем. Получается обратимый препроцессор, что есть гуд (в отличие от классических препроцессоров, которые делают необратимое преобразование).

Мне кажется что отображение кода в виде, отличном от его хранения в исходниках будет приносить много путаницы.
Иногда нужно поглядеть на код в чужом редакторе, и будет странно видеть там незнакомую глазу конструкцию. Особенно это касается тех, у кого опыт на Джаве небольшой.

Про closures: В .NET есть понятие "делегаты". Это такой безопастный указатель на функцию. Именно на функцию, а не на сам класс.
Мы просто пишем метод, заворачиваем его в делегат, и передаем куда-то дальше, где кто-то вызовет у него invoke(). Если метод не статический, то куда-то туда (думаю) отправляется и ссылка на объект (неявно).
По сравнению с Runnable это -- усложнение языка (вместо обычного класса появляется какая-то новая конструкция), но она уменьшает кол-во кода.
Если же описывать метод инлайново, то получится как раз что-то типа:


some.doSomething( new someDelegate() {
//...
}
)


Кроме того у делегата можно описать сигнатуру. Возможно было-бы здорово иметь что-то похожее в Java.

Про set / get.
В C# свойства назвали полями, а свойствами назвали такую конструкцию, которая внешне выглядит как поле, но по сути является методом.

//Эта строчка кода компайлером превращается в user.set_lastName("pupkin")
user.lastName = "pupkin";


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

отображение кода в виде, отличном от его хранения в исх

Иногда нужно поглядеть на код в чужом редакторе, и будет странно видеть там незнакомую глазу конструкцию.

Все современные Java IDE по умолчанию сворачивают секции import-ов, т.е. открывая файл вы её там не видите, хотя она там есть. Это путает начинающих разработчиков?

Я совершенно согласен, что нельзя заменять шаблонный код на другой код в IDE (это делается в новой версии языка). IDE может заменять шаблонный код на некое другое графическое представление, которое ясно подчёркивает тот факт, что вы видите лишь "свёрнутую" версию шаблона, и нажав на какую-нибудь кнопочку "+" можете посмотреть что у него внутри.

Вот, собственно, некие практические эксперименты:
http://friendfeed.com/e/4a8bcbbf-5192-4158-b2d0-f39e85cf9be6/Closure-folding-suggestion/

А над чем эти эксперименты проводятся? Я не смог понять контекст предложения. И ограничен ли scope этих экспериментов только closures? Я тут осознал проблему из-за однобокого поведения современных IDE - см. этот коммент.

Кажется, обнаружился проект по теме обсуждения:

http://code.google.com/p/lambda4jdt/

this post is really useful topic and I guess that I would like buy essay (http://www.essaysexperts.com) or essay writing (http://www.essaysexperts.com) to get know more information close to this from writing service (http://www.essaysexperts.com).

  • 1
?

Log in

No account? Create an account