Hi David, I'm very happy having people to give their opinions, it means, to me, we have some kind of community.
On Tue, 2020-06-09 at 06:22 +0900, David Leangen wrote: > > > My point is that (1) the “core” should remain in Java alone, not > > > because Java is so awesome but simply just to avoid unnecessary > > > complexity, > > > > Well, one should not confuse `complex` with `familiar`. Java is > > `familiar` to many people but is way more complex than Scala in > > many > > ways. > > I totally agree with the point: one should not confuse “complex” with > “familiar”. I suppose the only thing I don’t agree with in this > sentence is the choice of character ( ` ) for a quote. That goes > against everything I have ever learned, and is forbidden by my > religion. You are right, it's just lazyness because I changed from an AZERTY keyboard to a QWERTY one and back-quote is simpler to type. I won't do that in the future. > Seriously though, my assumption was that we were talking about the > development domain. I was thinking about “complex” as described so > well by Rich Hickey: > > —> https://www.infoq.com/presentations/Simple-Made-Easy/ > > If I need one language, which comes with a syntax, a set of rules, a > compiler/interpreter, a set of tools… there is one (big) “thing”. But > then if I need to add another language which also has its own syntax, > rules, quirks, tools, compiler/interpreter… now there are two (big) > “things”. It seems to me that changing from one thing to two things > is by definition more “complex”. > > I think it is possible in my description to change the words “Java” > and “Scala” to “language A” and “language B” and the idea shouldn’t > change. > > Heck, you could even switch the two around and I think it would still > express what I intend. Would the answer be the same if most of the > code was in Scala and somebody was proposing to add more Java? I pretty much agree with "the more you add the harder it is for somebody new to the project to be ready to work on the codebase". But if you follow that principle stricly: * you don't go from java 5 to java 8 because people are not ready to write functional-ish java (the knowledge shift is huge) * you don't use async APIs because it's harder than synchronous APIs * you don't adopt reactive programming because it's yet another complex piece of knowledge And so on. And not adopting any new thing basically makes a obsolete and/or dead project. > (Actually, if somebody really hates Java that much, if the entire > code base were changed to a different language, like Scala, perhaps > THAT could be a good thing!) But no software of this size can be shifted overnight to another language. > My answer was intended to be agnostic to __which__ language is used, > but was more about being cautious about adding complexity > unnecessarily. Or if there is value to adding complexity, to take > appropriate steps to at least mitigate the complexity. > > The idea of “familiar” should be applied both ways: both to anyone > who resists because it is not familiar enough, and also to anyone who > is excited because it is so much better than Java. > > > So `yes`, I totally agree with this point!! > We did resist for years, actually. I can list here some things that we really benefits from adopting Scala: * POJOs (datastructure) are hundreds of lines today with potential errors and we write builders everywhere to workaround the lack of named parameters in method calls. It's really a waste of time. We could have adopted Lombok so solve that but it's harder to setup than integrating Scala and Scala `case class` are way better then Java libraries trying to provide that feature. BTW, I know that Java is getting records in Java 14 with an experimental flag but it mean waiting for the next LTS before using it (java 17?) and switch the James runtime. We are talking about a several years delay * Algebraic Data Typdes (ADT): Java doesn't offer sealed hierarchies nor pattern-matching on datastructures. If Java did a lot to spread OOP in the computer science world, OOP does not fit all problems. If you look at the PR https://github.com/linagora/james-project/pull/3309 that triggered that thread, you'll see it's about implementing search. Search is a tree of conditions with a static grammar: an ADT with pattern-matching is without a doubt more appropriate than OOP for that. * When working with Java streams or reactive streams, because of checked exception in Java, you spend much time cheating the compiler to use checked exception in lambdas, something Scala doesn't require. * Again with streams, we spend so much time calling `.stream()` then `.collect()` and copying immutable structures where Scala offers persistent datastructure where you can just call `map` on a structure and be done with it. We also thought about including vavr library for that in the past and refrained because of too small return on investment of it. * Json serialization is a pain in Java as soon as you want separation of concerns. You can't use annotation on your POJOs so you either create DTO classes with lots of annotations or you can use mix-ins with Jackson. In both cases you end with a huge pile of boiler plate. Type- classes in Scala solve that issue very eleganlty (see what we do we play-json for instance). In conclusion: we have a lot of reasons to switch the James codebase to a more modern language (and keep in mind that java is adopting most of Scala features with a 10 years latency before answering Java is modern). We did study some candidates and proposed an ADR with rationales. The complexity of James project is so high that I doubt using a second language is really a problem with respect to the essential complexity of the project and if it can help making the code more readable and express concepts in a more obvious way, it could balance having to learn this new thing. I think that this debate is interesting nonetheless and I thank you again for your email. Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
