Questions in Response to Rod Johnson's "Scala in 2018" Scala Days 2013 Keynote Talk
The following is a list of controversial quotes from the talk with time markers. Interspersed among these quotes are questions many in the Scala community would like for Rod to respond to.
This may be useful for a panel discussion with Rod.
Scala has this incredible combination of flexibility, while retaining strong typing. And that just really works for me. I've always been a fan of strong typing. And to have the ability to have strong typing while also having a flexible syntax I just find very impressive. [18:05]
Java is pretty much equal to #1 programming language with C in world. Is that an accident? Is Java very bad? Does Java suck massively? Is this a complete random accident? I don't think this is a complete random accident, and there are also some things very good about Java, and we should also consider them. [19:40]
In your Scala Days talk, you make claim that Java is popular because it is good. How does popularity correlate with intrinsic goodness? This rationale is often cited as "argumentum ad populum" or "appeal to popularity." Can you refine your argument such that it does not seem to suffer from this logical fallacy?
Java has really pretty awesome tooling. [20:40]
Many claim that Java's tooling is largely an artifact of poor language design and ecosystem. For instance, IDEs have many plugins for Maven POM files, JSPs, and Spring XML configuration -- largely because libraries opted for XML over using Java's type system effectively. Do you agree with this evaluation? Can we do better with typesafety and a good compiler?
We have a mix of folk in our community, and there do seem to be quite a few people that aren't focused on solving real world problems. And I think that is a bit of a problem overall for Scala. [21:30]
In your Scala Days talk, you assert that Scala has a problematic community not solving real world problems. Do you have any explicit instances of this problem?
Would the ScalaZ library fall in this category of not-real, impractical work? Do you believe people are using this library or others like it more for pedagogy than professional work?
Java as a culture of readable, though verbose, code. We [Scala] have a culture of unreadable clever code. [22:55]
In your Scala Days talk, you claim that Java has a culture of readable code, whereas Scala does not. When you say "readable," do you mean "comprehensible?" Can you see the argument that these names taken from Spring
- AbstractAnnotationConfigDispatcherServletInitializer,
- AbstractInterceptorDrivenBeanDefinitionDecorator,
- AbstractInterruptibleBatchPreparedStatementSetter,
- UnsafeQualifiedStaticCharacterFieldAccessorImpl
are readable, but perhaps not comprehensible? Perhaps they are only comprehensible when one is familiar with Spring. In this regard, is it possible that both Java and Scala are equally incomprehensible to the unacquainted?
Also you claim that "cleverness" is bad, but this raises a lot of questions about when intellect is appropriately applied and when poorly. Perhaps you are really only concerned when clever solutions are not familiar. As a case in point, EJBs are certainly familiar to many people on the JVM. Alternatives are often unfamiliar, and sometimes clever. Your rationale appears to support a return to EJBs and enterprise standards. Please elaborate on why this is or is not the case.
Java is not going away, so we want to really play nicely with Java, not just completely replace it. [22:30]
In your Scala Days talk, you express concern that Scala libraries are rewriting quality Java libraries either redundantly or poorly. What projects do you feel are attempting to replace Java libraries completely in a way that's ill-advised? You spent some time talking about Dispatch, but that's merely a thin wrapper around the Java HttpAsyncClient library.
Myth #1: It's good to be clever. . . It's not obvious from a piece of code where you might go to look to find how those things fit together. [23:50]
One of the common responses to this is in the Scala community is a rigorous mathematical proof that Scala is simplier than Java. [24:55]
If you look at Java code, you tend to be able to read it. If you look at Scala code, you will encounter Scala code that is pretty much impossible to read. I would argue that's not good Scala code. I would argue that if you write good Scala code it will be easier to read than Java code, because it will be more elegant and less verbose. [25:15]
Mathematics-based Scala code is often elegant and less verbose but not easy to read for people with no understanding of mathematical notation. However, mathematics provides us a stronger ability to do many things that programmers value, including high degrees of abstraction, reuse, composition, and correctness -- higher than anything one can do traditional Java patterns. Why isn't this worth the cost of writing code that may not be readable to the unacquainted? Can they not be taught in the same that way that people not acquainted with Spring or Hibernate are taught?
We should not prioritize cleverness as a valuable metric of code quality. [25:40]
It is also hard [in Java] to hang yourself. [26:15]
Many people migrated from overly-complicated enterprise Java web projects to Rails projects. Some people similarly have moved from overly-complicated Rails projects to Scala. Is it possible that all languages have rope to hang ourselves, and that the language can do very little to hinder bad programming?
This is the so-called Dispatch periodic table. The Dispatch API consists largely of bizarre custom operators. [28:00]
Regarding symbolic operators (as in Dispatch), do you believe that POSIX Shell should abandon redirection/pipe combinators like "|", ">", and "<"? Which do you find more readable?
tail -f </var/log/server.log | grep --line-buffered DEBUG >~snippet.log
(tail.streaming readFrom "/var/log/server.log")
.pipe(grep(DEBUG))
.writeTo("/home/user/snippet.log")
Many people people prefer the former. Why are they wrong? In fact, Dispatch's new API leans heavily on a Shell-like notation.
If you can concede that these symbolic operators make sense and sometimes better imply operator precedence (even though they are not traditional arithmetic operators), how would your advice have applied in the days when Shell's pipe/redirection notation was first designed and not yet familiar?
You need to converge upon one good way, and make that essentially the industry standard approach. This is actually something I think the Rails community did really well for Ruby. [31:45]
Your Scala Days talk asserts that we need to converge upon "one good way" much as Rails has done for Ruby. Many in the Rails community have had issues with standardized mandates from a framework. In fact, there are notable Scala success stories born from Rails nightmare stories. Complaints with Rails often stem from propping up a standardized solution that does not have enough flexibility (abstraction, performance, etc), and then spending too much time patching the standard's inadequacies. It seems that standardized "one good way" approaches always have this problems. What's wrong with building an ecosystem of small highly compose-able pieces without heavy prescription?
To look again at the example of Perl, essentially people write Perl in so many different styles, that it's not uncommon to find a line of code that a substantial proportion of the Perl community would find hard to understand. [32:10]
You claim in your Scala Days talk that Perl suffers from people writing Perl in too many styles. Can you cite an instance of Scala written in so many different styles within the same API or team that the very authors can no longer maintain it? Does the Scala ecosystem/community need to address this problem explicitly? Or should this problem be addressed more by the professionalism of the programmers to only implement what they can comprehend and maintain?
Another myth that seems to be common in the Scala community is that ignorance should be punished. [33:15]
With respect to this comment is correcting someone and helping them learn a better way "punishment?"
Java community is over 50 times larger than the Haskell community. [36:50]
Another myth that seems to be popular in the community is that object-oriented programming is bad. . . If you don't like object-orientation Scala is not the language for you. [37:45]
You made the comment that "if you you don't like OO, then Scala is not the language for you." What do you think object orientation is? Your Scala Days talk is extremely vague on this point. Functional programmers often care most about side-effects (which is how computation becomes non-functional in a mathematical sense). Do you believe OO require side-effects? If not, then where is the tension? Do you know of any instances of Scala programmers not ever using classes or traits (beyond ADT-encoding with case classes) and only using functions on objects?
Another myth that seems to be quite prevalent is that this language is so good that we don't need lousy frameworks. . . Most real world programming has little to do with elegant expression of algorithms. It has to do with interacting with the real world is a total mess. Wherever you look. . . databases, transaction management, legacy systems, network calls . . . it's a nasty mess out there. [38:50]
In the context of the quote above, many companies (for instance, Precog and CapitalIQ) have employees that work really hard to wrangle the "mess of the real world" with elegant algorithms. In many ways they have been successful, and often talk and educate people on their successes, which often involve small APIs that are both typesafe and highly composeable. Why shouldn't the Scala community strive to understand these techniques and seek more of them out?
Young communities [like Scala] tend to be arrogant. [40:45]
Obviously this poster [Simon Ochsenreither] is one of the more naive members of the community. However, it's a reductio ad absurdum. Because we've got a great language, problems that other have wrestled with will be trivial for us. We're going to write this in a single line of code. [42:10]
In your Scala Days talk, you call for a culture of respect, stating that respect breeds respect. However, you then proceed to publicly quote both Tony Morris and Simon Ochsenreither without attribution (even alluding to Simon as "one of the more naive members of the community"). Many in the community easily recognized through tone and content the identities of these posters and felt you'd slipped into an ad hominem rhetoric. How would you respond to those that found your presentation as confrontational as the people you were calling out? You talk about building a positive community. What bridges are you making with people in the Scala community doing more FP to offset the perceived attack of your talk?
If you have ever written an OR mapping tool, you can't do it in a single line of code. And the reason is because you are dealing with a very murky real world. [42:40]
Exhibit A: Scala ORM in Practice [43:30]
In your Scala Days talk, you show an example of monadic composition, but then assert that it's an ORM tool. When many people think of ORMs, they think of "active" objects that hide interaction with a database or frameworks that work hard to shoehorn complications like subtype inheritance into the relational model.
The monadic composition you illustrated is very much like building SQL expressions with snippets of strings, only in a very typesafe way. This is not terribly different from Hibernate's Criteria API, only more typesafe and more composeable/flexible. Would you prefer building queries with raw strings? Do you agree that monadic composition has nothing to do with "object" mapping, but rather treats data as merely typed tuples from the relational model?
I think we should look at the Java solutions, before we reimplement new capabilities in Scala. We should view Java as an embarrassment. . . The first question should be does it already exist in Java. The second question is can we make it idiomatic Scala. [44:50]
Many implementors of Scala libraries have already gained a mastery of various JSR specifications, their reference implementations, and popular libraries including Spring, Guice, Hibernate, Guava, and many others. Can you cite an example of where an author of a popular library clearly has no indication of prior art in Java?
Additionally, using Spring as a case in point, many people have solved the problem of "dependency injection" by merely passing in a parameter to a function. There exists projects that scale this technique extremely well when using the higher levels of abstractions that Scala enables. Do you not feel that before anyone builds a "framework" in Java they should first see if the language requires one at all?
The proportion of junk [in Scala] is definitely higher than it is in Java land. [47:00]
How do you begin to qualify this statement? In your keynote talk, you clearly highlight how much more mass adoption Java has beyond Scala. Do you not agree that mass adoption invariably leads to a much higher density of programmers that make "junk?" Can you please explain exact libraries that you think are "junk" and how you qualify them as such relative to "junk" in the Java community?
Another problematic myth is that purity matters. [47:15]
What exactly do think "purity" is? Are we talking about not having side-effects? Or something else? If someone implemented the "monitor" pattern in Java, but didn't synchronize a method properly, would "you don't need purity" be a valid response? Why is functional programming any different?
When you have a type-safety hammer, OR mapping may not actually be a nail. . . We need to accept when you get into an inherently messy real world, intellectual purity can be quite dangerous. [48:50]
There's no way the Scala compiler is going to be faster than Java. It has a lot more work to do. [50:40]
Do we actually want Scala to be mainstream? [53:15]
In your keynote talk, you explicitly have as a bullet point "do we actually want Scala to be mainstream," but then you immediately move into statements that assume that we've agreed that we do. What exact benefits do we getting mass adoption? Wouldn't Scala be better if we had a high density of strong programmers and worked really hard to educate programmers to reach the same level of competency? Mass adoption often leads to huge masses of poorly written legacy code bases. This only serves to sully the reputation of the language and ecosystem. Why is this better for us as programmers or society at large? Would it be okay for Ruby, Python, Go or one of the other languages to sustain the pressures of mass adoption, leaving Scala to focus more of writing code of a high quality?