I'm also against adding more complexity in James.

My arguments against adding scala to James are:

- It adds another language that is more complex that Java - operator
overloading, much more dense language (easier to write, harder to read).

- Extra build and runtime dependencies. Scala is another compiler step
and if I remember quite slow (might have changed). It also requires adds
the library to the applications. More bytes to push, more surface area
to atack. Ideally we should have NO outside dependencies in James core.
Hard but doable - Lucene does it.


I do believe we should make James easy to consume from other languages
but I don't believe we should add more things to James. We should strip
them off, starting with dependencies.


Right now I'm trying to "mvn compile" master and I can't.  mvn clean
package also fails after running for 30-45 minutes on a Ryzen 7.  I feel
that does not work.

The project has 408244 lines of Java  and takes longer to compile than
the linux kernel [1]. I believe we are doing something wrong here.

As a developer I should be able to work on James and build it locally,
otherwise things are not going to move forward.

Every new tool and external dependency adds complexity.

I believe we should avoid adding more languages to James.

I personally prefer Clojure but I will not add Clojure to James core for
the same reason. I will build apps on top of James with Clojure for sure.


-----

[INFO] Total time:  11.296 s
[INFO] Finished at: 2020-06-09T00:30:17+03:00
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
net.alchim31.maven:scala-maven-plugin:3.4.4:compile
(scala-compile-first) on project event-sourcing-event-store-api: wrap:
org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException:
Could not resolve following dependencies:
[org.apache.james:event-sourcing-pojo:jar:tests:3.6.0-SNAPSHOT (test)]:
Could not resolve dependencies for project
org.apache.james:event-sourcing-event-store-api:jar:3.6.0-SNAPSHOT:
Failure to find
org.apache.james:event-sourcing-pojo:jar:tests:3.6.0-SNAPSHOT in
https://jcenter.bintray.com was cached in the local repository,
resolution will not be reattempted until the update interval of central
has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn <args> -rf :event-sourcing-event-store-api

-----


[1] https://phoronix.com/scan.php?page=article&item=ryzen-2600x-2700x&num=4


La 09.06.2020 00:22, David Leangen a scris:
>>> 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.
>
> 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?
>
> (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!)
>
> 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!!
>
>
> Cheers,
> =David
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
-- 
Eugen Stan
+40720 898 747 / netdava.com

<<attachment: eugen_stan.vcf>>

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to