Learning Scala as the First VM / Compiled Language - Workflow Issues

I come from the background of PHP / Python / Javascript, and lately I have become very interested in Scala, namely Akka, coming from a web point of view.

I have a very difficult time, although with a common workflow, problems are compared to interpreted languages ​​such as those that I described.

In general, I try to code, test the results, code and repeat. This stops when even changing one line in the 20 line class takes up to 30 seconds to compile and run. Is this really normal? Do I just need to build, build, build, and then come back in 30 minutes or an hour later and compile / check?

(I am using IDEA with SBT). Do I need to specifically learn how to use Maven other than linking to repositories?

Thoughts? Advice?

+6
workflow scala intellij-idea sbt
source share
5 answers

I think you are on the right track with the idea and SBT. You tried

~compile 

This will automatically detect changes in your source. For web applications you can do

 jetty-run 

followed by

 ~prepare-webapp 

To constantly compile and relocate the application to the marina. Makes Scala dev very similar to Python web development.

I usually found that SBT compiles very quickly, especially the file size you are talking about. When I save the changes and move on to my SBT invitation, do this.

Another handy aspect of SBT is the REPL, which will load your project and its dependencies:

 console 

You can reload any compiled changes with

 :replay 

in Scala REPL.

EDIT: I think I should mention that you can play with a simple class using the main method. If you create a file called src / main / scala / Foo.scala that looks like this:

 object Foo { def main(args: Array[String]) { println("Hello World") } } 

And the file project / build / Build.scala:

 import sbt._ class Build(info: ProjectInfo) extends DefaultProject(info) { override def mainClass = Some("Foo") } 

Then at sbt prompt you can do

 ~run 

To continuously compile and run the Foo.main method. You may need to reboot in sbt first. It seems that in 2-3 seconds from saving changes to getting the result. Then you simply edit, save and see the changes. This is a pretty good workflow.

Also, don't forget the REPL - definitely an important tool for learning Scala. You can find out a ton playing with it interactively.

+8
source share

IDE Support:

With a static input language, I find that I am doing less workflow than with dynamic typing, but this was only possible due to the excellent support of the IDE (information about typing allows it to detect errors earlier and give precise recommendations while you are editing), therefore it saves some time in this code review loop that you described.

However, the WMA> IDE support in IDEA is not yet at the Java level, for example, both when detecting errors during editing (IMHO) and in compilation speed.

REPL / Script support:

Don't forget that you can still use Scala REPL, the workflow is pretty much the same as what you would use in Python, for example.

IDEA + Scala Speed:

You can refer to this question to learn more about the speed of IDEA + Scala.

+5
source share

I am using the JRebel plugin with maven . I will disable the NetBeans function for saving compilation (I don’t know if intellij is intellij ) and run scala:cc is a continuous compilation target from the console. It waits for any changes in the source code, so after you make them, the file will be compiled, copied to the /target directory, and then included in the working virtual machine. The procedure takes a few seconds depending on the size of the file (I assume that you are doing web development since you mentioned PHP and JavaScript ). The fsc server is running in the background, which is also one of the reasons why compilation is speeding up.
There are some minor flaws, you cannot change the superclass, which means you cannot go from AbstractFunction1 to AbstractFunction2 (which are anonymous functions) - changing (x) => x to (x,y) => x + y means that you need to restart the server.
Useful links:
scala: cc
jrebel

+2
source share

One of the advantages of statically typed languages ​​is that the type system can capture several types of errors / errors. Therefore, theoretically, you do not need to go through rigmarole too often.

Of course, there are many changes, especially in the user interface, that only eyeballs on the screen can check. All I can offer is good modulation to save compile / build time. And unit tests. I don't know about the community you came from, but in java / scala, unit tests are highly recommended. You will find out if the code worked so fast.

The answer comes down to the following: try to avoid the need to build and restart to check your work as much as possible.

+1
source share

My Python-like workflow - which leaves me with very little latency - usually goes like this:

  • Rotate what I'm trying to do in the library (paste it in .jar and add it to the classpath).

  • Work on the new code in the editor, but paste it into the REPL instead of compiling separately. After it works well, add unit test.

  • Put the new code in the library. Repeat.

I can do this on a netbook and not wait longer than 3 seconds for any step.

+1
source share

All Articles