Полагаю, что среди действующих Java-разработчиков (т.е. тех, кто зарабатывает себе на жизнь разработкой на Java), найдется немало желающих сменить Java на что-нибудь более удобное, мощное, но не слишком сложное. Такой заменой лично мне ранее представлялся язык Scala. Но, предположу, что его сложность уже давно превысила все мыслимые для мейнстрима пределы :) Поэтому обычные, средние разработчики, которым язык программирования нужен не для решения головоломок и разминания мозгов для удовольствия (к коим я отношу и себя), на Scala перейдут без энтузиазма и только в приказном порядке :)
Может я преувеличиваю, но мне кажется, что есть достаточное количество Java-программистов, которые с интересом смотрят на развитие Ceylon-а и Kotlin-а. Очень надеюсь, что не без основания. Мне самому, например, очень интересно будет посмотреть на официально выпущенные релизные версии этих языков (могу ошибаться, но, по-моему, ни один из них пока не дошел до версии 1.0).
Однако, на днях с удивлением и интересом обнаружил, что для JVM уже есть очень симпатичный язык, который, по первому взгляду на него, производит впечатление правильно сделанной замены Java. Это язык Gosu.
Сразу скажу, что на Gosu я не программировал. Мои знания заканчиваются где-то вскоре за пределами краткого введения в язык + еще нескольких материалов, ссылки на которые я дам в конце заметки. Но то, что я увидел при беглом просмотре, выглядит весьма привлекательно. Так что, возникни у меня сейчас настоятельная необходимость начать делать что-то большое и серьезное на JVM, я бы в первую очередь посмотрел на язык Gosu.
Если попробовать тезисно набросать список достоинств языка, то получится что-то вроде:
- вывод типов;
- поддержка т.н. properties (лично для меня это не есть интересная фича, но для мира Java, где принято делать setter-ы и getter-ы на каждый чих, облегчение этой работы не может не радовать);
- null safety (специальный синтаксис для обращения по ссылкам с проверкой нулевого значения ссылки);
- именованные аргументы методов и аргументы со значениями по умолчанию;
- возможность делегирования реализации интерфейса члену класса;
- конструкция using (аналог таковой из C#, своего рода замена C++ному RAII);
- лямбда-функции, они же closures, называемые в Gosu блоками (по аналогии с Ruby);
- возможность расширения чужих классов своими методами под названием enhancements (что-то в духе extension methods из C#);
- более простые и мощные генерики, чем в Java;
- встроенный в язык string interpolation (т.е. возможность писать print ("${s1}"), где s1 -- это переменная, строковое значение которой будет вставлено в аргумент для print);
- удобный синтаксический сахар для работы с коллекциями/контейнерами (достигнутый как синтаксическими возможностями языка, так и enhancement-ами над стандартными классами коллекций);
- поддержка REPL;
- при этом все статически типизированное, с полной поддержкой Java, с наличием плагина для IDEA.
В принципе, уже этого было бы достаточно, чтобы дать языку шанс в новом проекте вместо Java. Но главной killer feature языка его авторы считают такую штуку, как Open Type System. Боюсь сейчас соврать (т.к. на Gosu я не программировал), но это выглядит как система плагинов, которые расширяют компилятор Gosu информацией о новых типах/классах. Причем откуда берется эта информация для компилятора не важно -- это может быть XSD схема, описание SQL-ных таблиц, URL-сайта для Web-приложения или что-то еще. Важно, что после того, как соответствующий плагин задействован, программист может работать с подключенной через плагин сущностью как с обычным классом. Вот пример работы с XSD от разработчиков Gosu:
XSD описание:
<xs:element name=”DriverInfo”>
<xs:complexType>
<xs:sequence>
<xs:element ref=”DriversLicense” minOccurs=”0″ maxOccurs=”unbounded”/>
<xs:element name=”PurposeUse” type=”String” minOccurs=”0″/>
<xs:element name=”PermissionInd” type=”String” minOccurs=”0″/>
<xs:element name=”OperatorAtFaultInd” type=”String” minOccurs=”0″/>
</xs:sequence>
<xs:attribute name=”id” type=”xs:ID” use=”optional”/>
</xs:complexType>
</xs:element>
<xs:element name=”DriversLicense”>
<xs:complexType>
<xs:sequence>
<xs:element name=”DriversLicenseNumber” type=”String”/>
<xs:element name=”StateProv” type=”String” minOccurs=”0″/>
<xs:element name=”CountryCd” type=”String” minOccurs=”0″/>
</xs:sequence>
<xs:attribute name=”id” type=”xs:ID” use=”optional”/>
</xs:complexType>
</xs:element>
Это то, как с ним можно работать в программе:
uses xsd.driver.DriverInfo
uses xsd.driver.DriversLicense
uses java.util.ArrayList
function makeSampleDriver() : DriverInfo {
var driver = new DriverInfo(){:PurposeUse = “Truck”}
driver.DriversLicenses = new ArrayList()
driver.DriversLicenses.add(new DriversLicense(){:CountryCd = “US”, :StateProv = “AL”})
return driver
}
При этом разработчику обеспечиваются две важные вещи. Во-первых, он имеет полную поддержку от IDE, включая автокомплит, рефакторинг, всплывающие подсказки и пр. Во-вторых, если XSD-описание изменяется (например, меняются названия элементов), то код перестает компилироваться (т.е. полностью работает статическая типизация).
Повторюсь, авторы Gosu считают Open Type System главной отличительной особенностью языка (весь остальной синтаксический сахар либо есть у аналогов, либо в том или ином виде может появится в самой Java). В доказательство важности этой фичи приведу следующую обширную цитату:
Now with Ronin, the web framework for Gosu created by Gus Prevas, and Tosa, the SQL-focused OR layer for Gosu authored by Alan Keefer and Carson Gross, programmers can be extremely productive building hardcore web applications in Gosu with IntelliJ. Where else can you build web applications where the links are statically verified? Where else can you directly reference your SQL DDL and access queries with static types using code completion, all with no code generation? What other static language lets you modify types corresponding with your web content, even the structure of the types, and immediately see the results in the browser? (I’m going to keep going with this.) Can your JVM language directly expose arbitrary XML schemas where elements are types and attributes are properties with no code generation? Unless you have Dana Lank’s XSD/XML framework and your language is Gosu, it can’t. And even if it could, it couldn’t dream of having an IDE like IntelliJ refactor the name of an XML element and automatically rename all references to it in your code.
Не пользуясь Gosu и не пробуя создать свой плагин для поддержки нужных мне типов (например, через Open Type System в Gosu можно было бы вводить описания SObjectizer-овских агентов или сериализуемых посредством ObjESSty объектов) сложно судить, насколько это действительно важная вещь для разработки прикладного ПО с использованием Gosu. Но сам факт того, что эта возможность есть и она уже встроена в довольно простой язык, который при всем прочем сильно ограничивает полет фантазии и не дает писать комбайны в духе Александреску, не может не привлекать внимание.
Однако для меня неким "знаком качества" и "страховкой", которые заставляют смотреть на Gosu серьезно, а не как на очередную потенциально интересную штуку (коими сейчас являются Ceylon и Kotlin, и которой когда-то давным-давно была Scala), является то, что Gosu создавался и уже длительное время используется для разработки реальных вещей. Он появился внутри компании Guideware в 2002-м году. Сначала как скриптовый язык, затем постепенно он начал обрастать возможностями, которые нужны были разработчикам Guideware для нормальной работы. И постепенно превратился в серьезный и "взрослый" инструмент, который в районе 2010 года был выпущен в свет в качестве открытого инструмента. Т.е. для меня намного важнее сам факт того, что его делают нормальные программисты, которые занимаются нормальной разработкой (напомню, что таковыми были, например, Деннис Ричи (С), Бьёрн Страуструп (С++), Джеймс Гослинг (Java), Андрес Хайлсберг (Dephi, C#) и таковым не был, например, Мартин Одерски (Scala)). В таких условиях вероятность получить практичный язык для повседневных задач намного выше, чем когда развитием языка занимаются ученые от computer science или же обезличенные забюрократизированные комитеты.
Еще один фактор, который сделал бы для меня Gosu более предпочтительным, чем Ceylon или Kotlin -- это объем документации по Gosu, которая доступна на сайте языка. По себе знаю, что снабдить подробной документацией самодельный инструмент, который постоянно используется и постепенно развивается, это намного сложнее, чем создать и развивать этот инструмент.
Ну и еще один очень важный фактор, который крайне субьективен, но именно поэтому и важен лично для меня. Это созвучие мыслей, мнений и идей, высказанных автором языка Gosu с моими собственными мыслями на счет того, каким должен быть мейнстримовый язык. Полагаю, что фанатам Scala или Haskell эти мысли и мнения будут казаться унылыми стенаниями замшелых старперов-ниасиляторов. Ну и флаг вам, дорогие товарищи, в руки. Работы хватит для всех.
А теперь обещанные ссылки:
- gosu-lang.org -- сайт языка;
- getting started -- краткая информация о языке, практически рекламного характера. Хороша для того, чтобы составить впечатление о том, привлекает ли язык с эстетической точки зрения;
- небольшая презентация о языке Gosu в виде PDF, хорошо рассказывающая об основных особенностях языка от его автора Скотта МасКинни;
- полная документация по языку;
- серия блог-постов Скотта МасКинни о Gosu: Why Gosu?, Gosu’s Secret Sauce: The Open Type System, What Differentiates Gosu From Other Languages? (очень рекомендую эти заметки для того, чтобы вы сами могли понять, по пути ли вам с разработчиками Gosu или же вы совсем не разделяете их взгляды на то, каким должен быть современный язык программирования для массового применения);
- Upd. lazygosu.org -- еще один ресурс, который рассказывает об основных особенностях языка.
PS. Понимаю, что мои слова выглядят двусмысленно: мол, сам он язык Gosu использовать не будет, но советует пристально посмотреть на него. Тем не менее, не будь у меня багажа в C++, который я не собираюсь бросать, и будь у меня необходимость работать на JVM, я бы не стал ждать стабилизации Ceylon-а и Kotlin-а, а попробовал задействовать Gosu в какой-нибудь proof-of-concept разработке уже сейчас. Ну и, кстати говоря, если возникнет необходимость портировать SObjectizer на JVM, то Gosu будет первым в списке претендентов на язык реализации SObjectizer-on-JVM.
