DSL processing in Scala | Hacker News Reader

DSL processing in Scala

denis.papathanasiou.org

I'm still a scala newbie, so any comments/suggestions are appreciated.

The full source code is here: https://gist.github.com/dpapathanasiou/b9d85685a0381f1deea0

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

Good luck!

You should check out the Parser package in the scala standard lib. I maintain a few DSLs using this and it's an absolute dream.

https://wiki.scala-lang.org/display/SW/Parser+Combinators--G...

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.

The Parboiled2 framework is often used for building parsers.

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].

0 - https://github.com/lihaoyi/fastparse

Oh wow very good to know. We're just now looking to get to 2.11(very large codebase, upgrades are hard) so will definitely need to keep this in mind.

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

The meta-language is available here: https://github.com/combinatorylogic/mbase

For DSL implementation see string interpolation, http://stackoverflow.com/questions/10708136/how-to-create-ds...

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.

> 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.

Thank you!

> and much faster then my current gig's much smaller Gradle based Java 8 project

Yeah I call BS on that.

Scala's slow compilation doesn't really bother me that much but Java compiles at least ten times faster.

> much faster then my current gig's much smaller Gradle based Java 8 project

> I call BS on that [...] Java compiles at least ten times faster

Then it must be Gradle that's slow, probably the Groovy in it.

> 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.

These tunings are for the runtime, what compiler settings are you referring to?

1. Optimizing JVM parameters can speed up Scala programs.

2. The Scala compiler is itself a Scala program.

1 + 2 => Optimizing JVM parameters can speed up the Scala compiler.

> 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.

SBT uses incremental compilation. That might account for the difference observed by parent (on incremental builds only)?

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.

This works very well.

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.

Yuck. No wonder Lispers look down on us.

Reply on news.ycombinator.com