Some time ago, I made an XML literal syntax proposal for Scala 3, which is being discussed in the community. This proposal may herald the future of Scala 3, Scala.js, and binding.Scala. Why do you say so? It’s also worth talking about Scala’s current status as a programming language.
Martin Odersky, the original author of Scala, is also the designer of Generic Java (the predecessor of Java 5 generics), and the Java AC in Sun/Oracle’s JDK comes from Martin’s Java compiler. Considering that the language changed very little from Java 5 in 2004 to Java 8 in 2014. The foundation of the Java language over the last decade was laid by Generic Java and Javac.
After Genric Java, Martin designed Scala, which is mainly characterized by its high compatibility with Java bytecode, but also combines functional programming and object-oriented features. It is the product of transplanting the achievements of programming language academia to industry.
I understand that Scala’s design is to try not to be syntactically unconventional, but rather to mix up the old with the new, blending features of a modern language into an industrial tone similar to Java syntax. For example, ADT in functional programming languages is implemented by inheritance in Scala, which is easy for Java programmers to understand. Scala originally designed the assignment symbol to be “:=”, just like OCaml. After asking several questions, Martin said that he could not understand the “:=”, so Martin changed to the same “=” as Java.
Many complex applications are not suitable to be written in popular industrial languages such as Java, because the language features of these industrial languages are far behind the academic world, so it is very cumbersome to write, especially the poor ability to build DSL. But if you switch to academic languages like OCaml, Haskell, Idris, the ecology is too poor to use them.
Scala addresses this pain point. Because Scala is JVM-compatible but shorter and more expressive than Java (some studies show that beginners take about 1.7 times as long to read Java code with the same functionality as Scala code), Scala is often used in practice to develop core parts of complex systems that are difficult to implement. Things like Spark for data mining and Kafka for message queues are developed in Scala as core parts and then supported by Java users.
Scala is industry-friendly everywhere. Scala, for example, supports XML literals many years before JSX. Academic programming languages would never support this kind of “redundancy”. After all, a general-purpose language can parse XML with ease, so why design a syntax? But the practical value of industry is another matter.
In addition to JVM support, Scala can compile to JavaScript (scala.js). Scala in the front-end development world is similar to what it is on the JVM, compatible with JavaScript but more powerful than JavaScript, so it fits into the core of complex systems.
For example, Binding. Scala implements a data-binding MONAD, which is then used to implement reactive HTML templates in conjunction with Scala’s XML literals. Front-end development simply needs to copy and paste the designed HTML into a Scala file, replace the parts that change with variables, and the whole site is built. This approach, also adopted by React and JSX, has become the dominant approach to front-end development in 2018.
A framework like binding. scala is difficult to implement on a technology stack other than Scala.js. It doesn’t work in JavaScript because JavaScript lacks a functional programming infrastructure like Monad and can only do virtual DOM like React, which is much less time-consuming than precise data Binding in Binding.Scala (see Yang Bo: How to understand Yang Bo’s comment on DOM operation complexity? . It doesn’t work in Elm because Elm, an academic language, doesn’t have XML literals. By the way, Elm is far less mature than Scala.js because of its disconnect with industry development. Elm has 337 libraries in total, while Scala.js has 1315.
Unfortunately, Martin may be turning his back on his original intentions.
Scala 2’s XML literal is a syntactic sugar that automatically translates XML syntax into class calls in Scala.xml. Then, if you want to translate XML to another library (such as binding.scala), you need to write another macro or compiler plug-in that translates the scala.xml call into a call to another library. Macros or compiler plug-ins are difficult to write, so there are few libraries that take advantage of XML literals like binding. scala. So Martin decided that Scala 2’s XML literals were hard to extend, and…
Martin proposed that XML literals be removed from Scala 3. I can understand an academic language trying to keep it simple and eliminate redundancy, but I really can’t understand an industry-accepted language like Scala cutting out XML, especially in the days of JSX.
Therefore, FOR Martin’s proposal, I put forward a “name-based XML Literal” counter-proposal. I want Scala 3 to be able to translate XML literals into function calls that can be based on names, and users can translate XML literals into different libraries by importing them.
The features of Scala 3 will be determined by the SIP (Scala Improvement Process) committee. Martin, as the author of Scala, is certainly on the committee. Marin’s vision for Scala 3 looks like this:
In the future, I want to concentrate on making Scala a better language, with better tooling, as opposed to a more powerful toolbox in which people can write their own language .
This means that you want Scala to have a lot of tools and language features built into it, right out of the box, rather than giving other frameworks a toolkit to create specific languages. However, Martin’s idea runs counter to many of the Scala frameworks that make up the Scala ecosystem, which have chosen Scala for its ability to customize DSLS. Scala uses Scala as a DSL for HTML templates, Spark uses Scala as a DSL for MapReduce, and Chisel has a DSL for designing integrated circuits.
So during a September SIP meeting to discuss the future of XML, Martin stated that he wanted to remove XML: “Scala is instead a more Lightweight language than its competitors.” By contrast, other SIP commissioners, such as Sebastien Doeraene, author of Scala.js, are concerned about the impact of removing XML.
The fate of XML in Scala 3 is still up in the air. Whether this feature remains or not may give a hint as to whether Scala 3 can be a language for practical use in industry, or a lean, elegant, academic language.
Related links:
Binding.scala
Scala.js
Minutes of the September meeting of the SIP Committee
Scala XML discussion summary
name-based XML literal
Proposal to remove XML
The text/ThoughtWorks orson
For more insights, please follow our wechat account ThoughtWorks Insights