I don’t think that it should be any argument to the fact that implicits are a major hindrance to language adoption as I have previously laid it out in a pretty long epic thread. Nor do I think many would disagree that they can cause major headaches such as spending 7 hours looking for an implicit. However, as I have previously said I am actually a fan of the Scala language so I have been thinking about a productive and forward thinking solution to the problem without compromising all of the features that implicits legitimately provide. I think the solution to the problem is not so much the implicit themselves but the tooling.
Consider a java program for example that referenced a function not declared in the source, it would be simple to cmd-click (or ctrl-click) to navigate to that declaration and see where it is declared. Of course when you import a java class, you don’t automatically import the imports that the java class makes. This isn’t the case with implicits. So finding them is opaque, knowing where they come from is opaque and thus the nightmare. However, if you are using java and editing with vim the nightmare may be slightly less but still is impressive.
To solve this I think Lightbend (which is a major proponent and advocate of Scala) and ScalaLang.org need to start working together heavily with IDE makers such as IntelliJ on the tooling in an extremely cooperative manner. The current Scala tooling is more of a java tooling with some things bolted on. There is scant attention paid to making things that are tough in Scala and have no analog in java. An implicit conversion, for example, is lightly underlined in IntelliJ but you cant find what it was converted to or what the import was. If you use a macro (which I wouldn’t suggest by the way) then there is no tooling to let you know what the expansion of that macro will be. Furthermore almost every developer has been hit by obscure warnings that are less than helpful. Note that I don’t have anything against eclipse but I don’t prefer it as an IDE for many reasons. Instead of this tooling being something done by third parties or the vendors themselves, the two powerhouse organizations i recommended could work closely and provide tooling that makes the experience easy. Among recommendations I would propose the following:
- Objects that are implicitly converted should show up in a different color or have some obvious means of showing that the implicit conversion occurred, not a subtle light underline.
- There should be a command that you can execute in the key map that will take you to the declaration of the implicit conversion.
- When copying code from one file to another that utilizes an implicit conversion, the implicit should be imported for you.
- On the subject of imports, if implicits are imported as a result of an import that imports other things, the chain should be revealed in some kind of popup.
- If there are conflicting implicit conversions that render the resolution ambiguous it should be easy to navigate to where they are declared.
- The tooling should include a popup when you type the dot and do a ctrl-space expansion with a list of methods including the implicits available in another color or font weight or some other means to indicate it requires an implicit conversion to another type. For example if
doIt()can be called from an implicit conversion of a string the popup could show
MyImplicits.doIt()in orange indicating it comes from an implicit conversion.
- If you type code that results in a macro expansion there should be a key to popup a window that shows what the expanded form will be.
- Language syntax that is obscure from the point of view of Java developers should be able to invoke a popup to explain that syntax. Since Java devs are the most common converts to Scala this would aid adoption.
If the community really makes a concerted effort towards tooling I think adoption of the language will be even faster and these issues will not drive people out of an otherwise excellent language.
– Robert Simmons Jr.