Well done on posting this! it's a great way to learn and share your experience of learning new languages and get feedback. (just take the comments by face value without any sentiments, you should learn from them, not make them discourage you, ignore "my eyes are bleeding" type of comments or "Scala is sooo complexxx" unless they have some really constructive criticism in them...)
One tiny cosmetic suggestion that popped to my eyes since you asked for comments :)
def parseInputRange (s: String): Array[Int] = {
val ab = s.split(":").map(_.toInt)
(ab(0) to ab(1)).toArray
}
the `to` method is inclusive on the end of the range, so it is the same as until x + 1
Code looks solid otherwise...at least where I work the style would be to favor functional idioms over for loops but I think that's just personal preference.
That has been removed from the Scala standard lib and is now distributed separately. I am unsure how well it will be maintained by the community. As the other commenter said, parboiled2 is a good choice using macros and it is lightning fast. A lighter weight, runtime choice that was released recently is fastparse[0].
Just for fun and to illustrate what's in my opinion is wrong with Scala approach to DSLs, implemented the same DSL using a specialised meta-language: http://bit.ly/1U2PGlV
This doesn't seem to solve the puzzle. As much as DSL processing part is done, the whole point of the puzzle was to make the operations sublinear in time complexity.
To anyone here who works on a large, scala codebase as a team: how do you manage compilation times and narrowing code standards to a manageable set of idioms?
The "Scala is slow to compile" meme needs to die in a fire. At my last job we had a large Scala codebase and it compiles faster then our similarly sized C# project, and much faster then my current gig's much smaller Gradle based Java 8 project. We didn't do anything special: just a standard SBT project and a few logical modules.
As for feature set, we did code reviews across the whole team to keep everyone on the same page. That said, we used a very large part of Scala, and never really made an attempt to keep out of parts of the language. Our biggest battle was always with Scalaz, which we were always on the verge of adding, but never got enough team buyin.
> The "Scala is slow to compile" meme needs to die in a fire.
Martin Odersky has commented many times [1] that scalac won't be as fast as javac. The only link I could find right now is http://stackoverflow.com/questions/3490383/java-compile-spee... which is rather old; but I remember watching more recent videos (< 2 years old) where he makes the same points.
> The "Scala is slow to compile" meme needs to die in a fire.
Well said.
Additionally, I think people often forget that the same JVM tuning parameters available for production deployments are available for Scala compilations. These can make a huge difference in build times, especially since the default JVM parameters are understandably conservative.
> At my last job we had a large Scala codebase and it compiles faster then our similarly sized C# project, and much faster then my current gig's much smaller Gradle based Java 8 project
I never looked at that way before. We were a shop that used scala and Ruby.
So many of us come from interpretted languages and are used to code and tests reloading with no downtime. How does scalac match up to C# and Java compilation? I'd be interested in seeing the numbers.
I use the sbt command ~testQuick. That continuously recompiles scala files as soon as they're saved and reruns only the unittest(s) that are affected by the change.
For running my app I use the revolver plugin that offers the same thing: as soon as I save a file it is compiled and the app is restarted. When I use the Play framework this is supported out of the box: I save my file and refresh in the browser and see the changes.
scalac is definitely slower than javac, but I do wonder if half the complaints about speed are from people who don't realize you can leave SBT running but rather do an "sbt compile" every time and end up waiting for JVM initialization.
The full source code is here: https://gist.github.com/dpapathanasiou/b9d85685a0381f1deea0