Technologies

Read our account of the conference.

Scala DevTools Summit is an event which is impossible to pass by. The exchange of knowledge between experts in the field of scalable programming language was held on 11th and 12th February 2016 in Cracow.

The main topic of the conference was related to Scala developer tools. However, some of the presentations went beyond this scope – they covered the widely understood notion of support for developers, e.g. in the form of useful libraries.

The subject of the event, which was often emphasised by the participants, was unique. Large group of listeners shows growing interest in Scala, also among big companies.

Scala DevTools Summit — day one

After a short introduction and greeting, the first presentation — Evolving an ecosystem, was given by Iulian Dragos from Typesafe. It was on the development of Scala IDE. It is a programming environment for Scala based on Eclipse. The speaker talked about, among others, the history of the project and the main dilemma that appeared at the time when the project’s management was taken over by Typesafe, i.e. whether to develop the so far produced plug-in or write it from scratch. Eventually, it was decided to develop the project initiated earlier, but time has verified this decision — now, experts from Typesafe agree that it would be better to do everything from scratch (the initial concept assumed strong reuse of JDT and hacking with various techniques, including the use of aspects).
The next point of the programme concerned the refactoring library, The Scala Refactoring Library: Problems and Perspectives. The speaker — Matthias Langer, would at first simply use the library, and then became an important participant of the project through the implementation of a number of fixes for bugs he noticed when using the library. The most significant point of the presentation was the technical aspect of the operation of the Scala compiler.

Refactoring itself consists in proper conversion of the abstract syntax tree AST representing the programme’s source code. An important challenge is the lack of complete information in the tree, necessary for it to carry out refactoring. This is due to the fact that when creating an AST, information irrelevant from the point of view of the compiler, but important from the point of view of operating on the source code – e.g. comments, white spaces, is lost. An additional problem is also that various syntactic constructions in the source code (e.g. for, map) are represented in the AST in the same indistinguishable manner. As a result, changing an AST is not very difficult but the restoration of the resulting source code, in which lines not to be refactored are not changed, is troublesome.

Eugene Burmako in his presentation, What we learned in scala.meta?, presented a  solution largely concerning the problems outlined already by Matthias Langer. Scala.meta allows for representing source code which is more extensive than standard ASTs, hence it allows for providing other tools with the required information. It is worth reminding that Eugene is responsible for a very interesting ptoject Scala Macros allowing for metaprogramming in Scala with the use of a code during compilation.

The next speaker, Rory Graves talked about the Scalantor (Scalanator.io – Building a training platform on compiler tools). He presented the architecture of the site for learning Scala. The main element of this solution is the Ensime engine — a solution allowing for the construction of IDE. Scalanator.io is not yet launched, but it looks interesting.

Dave Gurnell showed how to effectively programme without IDE, The IDEless IDE. Efficient programming takes only a few scripts, few interesting ideas for searching files, a locally downloaded documentation and a good text editor. A very fresh and interesting presentation.

In How to be Free, Libre and Open Source Sam Halliday presented various types of licenses and issues related to copyrights, trademarks, etc. The requirements that Sam had to meet just to insert the Apple logo on one of the slides proved particularly interesting.

This is seemingly not related to the theme of the conference, but it is worth knowing what licenses should be issued for tools. A very interesting presentation on a subject that should make all open source projects users interested, not only Scala programmers.

In Scaps – Type-directed API Search for Scala Lukas Wegmann presented a site for searching functions based on their types in Scala libraries. The site may be tested online at http://scala-search.org — however its value seems rather academic.

Polish representative among the speakers — Wiesław Popielarski — talked about solutions for Scala IDE, which were developed in VirtusLab — an expressions evaluator and asynchronous debugger. These are interesting functionalities for the users of Eclipse and Scala IDE. For people using Idea it was rather a confirmation of their choice.

The last presentation on that day (Inside the IntelliJ Scala Plugin) was given by Pavel Fatin and concerned the method of developing plugins for Scala in Intellij. This was definitely a very good and technical presentation. It all worked well and addressed probably all issues from the previous presentations, starting from resizing fonts in IDE (this proved to be problematic in some windows in Eclipse) and ending with PSI (Programme Structure Interface) providing all information necessary for carrying out efficient operation on the programme’s syntax tree. Pavel showed how to make new code inspections in Idea – e.g. computing expressions directly in IDE and correcting the programmer’s work in a suboptimal manner.

The last part on this day was a discussion panel on the development of tools for Scala.

Scala DevTools Summit — day two

Day two began with Ensime — a different design. Rory Graves & Sam Halliday presented a solution which — as they said — was not IDE, but a tool for creating IDE. Estime allows for using preferred text editor while running an engine for compiling, syntax highlighting and autocompleting in the background. An interesting solution. Currently, it is widely used with various editors (Sublime Text, Emacs, Atom, Vim) and may also be used in web solutions, e.g. related to tools for code reviewing, pull request reviewing, etc.

Then, Simon Schäfer in An Attempt for a Tooling Platform to Supersede Them All talked about ambitious goals related to uniforming and connecting all tools based on standardised protocols. Someone pointed out that this occurs somewhat in .NET (however, this is backed by a strong single player). The presented ideas seem to be unrealistic.

The next presentation Rapture: A Stack for Scala built on Typesafety given by Jon Pretty was of a slightly different nature, since it concerned the library, not the tools. A very interesting and well prepared presentation, illustrated with live examples. The library is certainly worth of interest. In addition to using it in regular programmes, it is worth considering in scripts or ad hoc works.

After a lunch break, Guillaume Martres talked about the construction and extension of a Dotty (Hacking on Dotty: a live demo) compiler. Step by step, he showed how to make each line of the programme covered by entering information on its execution on the console. For this purpose, he first had to ‘plant’ within the code on programme instructions, and then emit an additional code. A very instructive presentation, since it shows how compilers work on the inside.

The next speaker, with a French accent, Alexandre Archambault, presented Easy dependency management with coursier. The presentation was appealing enough to inspire to spend a few minutes on implementing this solution after getting back to work. It is a plugin to sbt which significantly speeds up dependencies solving and their downloading time. This aspect was often raised against sbt, more specifically ivy, which is used by sbt by default.

Nepomuk Seiler in his Using SBT AutoPlugins to increase productivity and scale microservices architectures showed how in gutefrage.net, with the use of plugins to sbt, he simplified the construction of many projects realising different microsites. It was interesting how the construction in their projects was structured, so was the example of architecture based on microsites. Gutefrage is a Q&A social network.

Simon Ochsenreither in his The Implementation Challenges of Language Simplification started with a thesis that the implementation of some simplification in the language would have a beneficial impact on the ability to create programming tools more easily. Then the speaker showed complications caused by the introduction of these changes in order to finally conclude that it was practically impossible. The proposed changes make sense e.g. from the point of view of the application of Scala on platforms other than JVM (e.g. scala.js), however this means big problems with back compatibility — rather unacceptable for the environment). It was one of the least interesting points of the conference.

One of the last presentations concerned swagger — a solution for REST API documentation: Play-Swagger: Swagger Support for the Play Framework. First, Lauri Apple, who during the presentation referred to herself as “Jabłkowska”, said a few words about work culture in her company, mainly mentioning Radical Agility, which allows autonomous teams to work on projects based on the idea of microsites and communicate via REST. Then, Slava Schmidt showed how they use swagger and their Play plugin to create REST API specification.

The last presentation Perspective change: huge Scala project from tooling perspective concerned problems that occur in large projects based on Scala.

The conference ended with a few hackathons with the one concerning writing plugins for Idea by Pavel Fatin as probably rated the best by the users.

To sum up, ScalaSphere DevTools Summit 2016 included many good presentations, but there was also a reflection that the production of developer tools is an ungrateful issue — you can not count on generous profits and it is easy to be criticised by demanding users. Therefore, some speakers often encouraged to participate in joint improvement of individual tools.


Comments (0)

Leave a Reply

Your email address will not be published.