Uczenie się Scala jako pierwszego języka VM/kompilowanego - wyzwania związane z przepływem pracy

Question

Pochodzę z tła PHP/Python/Javascript, a ostatnio bardzo zainteresowałem się Scala - w szczególności Akka pochodzącą z punktu widzenia sieci.

Mam bardzo ciężki, choć ogólny przepływ pracy, problemy w porównaniu do języków interpretowanych, takich jak te, które opisałem.

Generalnie staram się kodować, testować wyniki, kodować i powtarzać. Staje się to niemożliwe, gdy nawet zmiana jednej linii w klasie 20-wierszowej zajmuje do 30sekund, aby skompilować i uruchomić. Czy to naprawdę normalne? Czy muszę po prostu budować, budować, budować, a następnie cofać się o 30 minut lub godzinę później i kompilować/testować?

(Używam IDEA z SBT) Czy muszę konkretnie nauczyć się korzystać z Maven poza połączeniem z repo?

Myśli? Rada?

Answer 1

Myślę, że jesteś na dobrej drodze dzięki Idea i SBT. Czy próbowałeś już teraz automatycznie wykryć zmiany w swoim źródle? Nie. Dla aplikacji internetowych, można zrobić

jetty-run 

następnie

~prepare-webapp 

Aby stale opracowuje i przesunięcie swoją aplikację do molo. Sprawia, że ​​Scala dev bardzo przypomina tworzenie stron w Pythonie.

Zwykle znalazłem SBT, który jest bardzo szybki podczas kompilacji, szczególnie plik o rozmiarze, o którym mówisz. Zanim zapiszę zmianę i przejdę do mojego komunikatu SBT, gotowe.

Kolejna przydatna SBT aspektem jest REPL który będzie ładować swój projekt i jego zależności:

console 

można przeładować żadnych zmian skompilowane z

:replay 

w REPL Scala.

EDYCJA: Przypuszczam, że powinienem wspomnieć, że można grać z prostą klasą za pomocą głównej metody. Jeśli tworzysz plik o nazwie src/main/scala/Foo.scala, który wygląda tak:

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

oraz projekt pliku/build/Build.scala tak:

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

potem na sbt prompt, możesz zrobić

Aby ciągle kompilować i uruchamiać metodę Foo.main. Być może najpierw musisz wykonać "przeładowanie" w sbt. Wydawało się, że od zapisania zmiany zajmuje 2-3 sekundy. Następnie edytuj, zapisuj i wyświetlaj zmiany. To całkiem dobry przepływ pracy.

Pamiętaj również o REPL - zdecydowanie krytycznym narzędziu do nauki Scali. Możesz nauczyć się tony, grając z nią interaktywnie.

Answer 2

IDE Assistance:

ze statycznym języku typowania znajdę się robi mniej tego przepływu pracy niż ja z dynamicznego typowania, ale to było możliwe tylko dzięki doskonałej pomocy IDE (informacja wpisując pozwala na wykrycie błędy na początku i podaj dokładne sugestie podczas edycji), więc oszczędza to trochę czasu w opisanej pętli testu kodu.

Jednak obsługa IDEA Scala w IDEA nie jest jeszcze na poziomie Javy, na przykład, zarówno w przechwytywaniu błędów podczas edycji (IMHO), jak i przy szybkości kompilacji.

REPL/Script wsparcia:

nie należy zapominać, że nadal można używać Scala rEPL, przepływ pracy jest dość dużo, jak to, co można byłoby stosować w Pythonie na przykład.

IDEA + prędkość Scala:

Można odwołać się do this question więcej dyskusji na temat IDEA + prędkość Scala.

Answer 3

Jedną z zalet języków statycznie napisanych jest to, że system typów może wychwycić kilka rodzajów błędów/błędów. Tak więc, teoretycznie, nie powinieneś zbyt często przechodzić przez rigmarole.

Oczywiście istnieje wiele zmian, szczególnie w interfejsie użytkownika, które mogą sprawdzać tylko gałki oczne na ekranie. Wszystko, co mogę zasugerować, to dobra modularyzacja, aby utrzymać czas kompilacji/kompilacji. I testy jednostkowe. Nie wiem o społeczności, z której pochodzisz, ale w java/scala, testy jednostkowe są wysoce zalecane. Dowiesz się, czy kod działał o wiele szybciej w ten sposób.

Odpowiedź sprowadza się do tego: staraj się unikać budowania i restartowania, aby sprawdzić swoją pracę tak bardzo, jak to możliwe.

Answer 4

Używam wtyczki JRebel z maven. Wyłączam kompilację NetBeans przy zapisywaniu (nie wiem, czy ma ona podobne cechy) i uruchamiam scala:cc - ciągły cel kompilacji z konsoli. Czeka na wszelkie zmiany w kodzie źródłowym, więc po dokonaniu niektórych, plik zostanie skompilowany, skopiowany do katalogu /target, a następnie na gorąco do uruchomionej maszyny wirtualnej. Procedura zajmuje jednostki sekund w zależności od rozmiaru pliku (zakładam, że tworzysz strony internetowe, ponieważ wspomniałeś PHP i JavaScript) W tle działa serwer fsc, który jest również jednym z powodów, dla których kompilacja jest przyspieszona w górę.
Istnieje kilka drobnych wad, nie można zmienić nadklasy, co oznacza, że ​​nie można przejść z AbstractFunction1 do AbstractFunction2 (które reprezentują funkcje anonimowe) - zmiana (x) => x na (x,y) => x + y oznacza, że ​​trzeba ponownie uruchomić serwer.
Przydatne linki:
scala:cc
jrebel

Answer 5

My Pythona jak Workflow - który pozostawia mi bardzo mało czasu oczekiwania - zazwyczaj wygląda następująco:

• Turn co usiłuję do zrobienia w bibliotece (przykleić ją do .jar i dodać do ścieżki klasy).

• Pracuj nad nowym kodem w edytorze, ale wklej go do REPL zamiast kompilować osobno. Kiedy to działa dobrze, dodaj test jednostkowy.

• Umieść nowy kod w bibliotece. Powtarzać.

Mogę to zrobić na netbooku i nie czekać dłużej niż ~ 3 sekundy na jeden krok.