4 ms·

I really disagree with this article. Type safety combined with Play's refresh-recompile trigger means it is not meaningfully less productive than PHP, and maybe

by Aqueous 13y ago

I really disagree with this article. Type safety combined with Play's refresh-recompile trigger means it is not meaningfully less productive than PHP, and maybe moreso because compiling is usually an indication of your program's correctness, so you don't waste time tweaking-reloading-tweaking-reloading. Compiling is slow, yes, but it saves you more time than it costs you because static typing means a whole class of bugs just never happen for you. I know that the IDE support is lacking but this doesn't really bother me since I don't use an IDE with Play apps. I always use a text editor, since I find that IDEs tend to do a bunch of things badly, whereas a text editor and a terminal each do a single thing very well. There's nothing you said about the features of an IDE that I couldn't do just as well with a well-defined find-replace (besides variable extraction - not familiar with variable extraction.) You can be productive in any language - Java, Scala. But I find that Scala's conciseness - the fact that I can do an operation on a whole collection of case classes using pattern matching and the collection API functions that would take 30 lines using classic Java - ends up making me more productive than I have been in those other languages. Maybe it's just me.

mason55 13y ago
> Not even sure why people need an IDE. For someone learning Play & scala in general I find the IDE to be immensely helpful in showing my type information and valid auto-completes. Rather than constantly digging through documentation I can see that, for example, some flatMap will give me a list of (Id, User) tuples, so then I can call map( case(id, user) => user) ) (or just map(_._2)) and pull out the user objects to get my list of users from my list of tuples. This lets me focus on the business logic and not spend all my brain power tracking types. I don't think I would have survived my first foray into building complicated composite ResultSet parsers in anorm without the IDE. I'm sure that as I gain more experience and all the functions become second nature I'll be able to track it in a text editor but for now I love my IDE.
- Aqueous 13y ago
  Yes, I edited that statement out - I'm sure people have good reasons for using IDEs, immediate type evaluation being one of them.
ebiester 13y ago
So, how do you write your unit tests? Within grails and guard (and other systems as well), I save my file and I have all the relevant unit tests running immediately. I have less than a second lapse. At least, when I was working within play, it was painful enough to discourage me from test driving my code, especially if implicits were involved.
- saryant 13y ago
  sbt ~test will run all your tests on file save. sbt ~test-quick will only run previously failed or new tests on file save. On one Play project we have ~160 test cases, including integration tests that spin up real Neo4j and Elasticsearch instances. Running the whole suite takes around 90 seconds. That would be far less if I did a better job separating unit and integration tests or mocking out the external dependencies.
- Aqueous 13y ago
  I spend most of my time running specs2 - unit specs - from the command line. I'm sure I could have sbt trigger on save but since I save pretty much constantly I'd have the tests running all the time. I will freely admit the compile time on tests is a bit extreme but I've found that it doesn't appreciably slow me down, since I typically run the tests when I'm confident the new code will pass. As for integration tests those run via Specs2/Selenium as well but I rarely run them from my own machine as they are continuously running on Travis CI whenever I push to our repositories.
- kasey_junk 13y ago
  Not sure about the state of the play framework, but the standard Scala build tool allows you to do the exact same thing as grails & guard using the ~test-quick operation.
kasey_junk 13y ago
I've tried dropping an Intellij several times while programming Scala, but have never figured out a VIM/Shell configuration that gives me what I need. That is: - Type safe re-factorings (why would I give up on my type system to just go grepping around my code base?). To be honest I don't use variable extraction as often in my Scala code as I did in Java, but to have never used it makes me think you are severely undervaluing the whole type safe re-factoring universe. - Automated import statements. - Configurable code formatting. The IDE space is improving dramatically in Scala, but I do think the Scala teams blessing of Eclipse was a mistake. They should have been writing more generic tools/hooks to empower their users in a wide variety of development setups.
- hp 13y ago
  The current direction we're hacking on is definitely toward shared code between Eclipse and other tools and editors.
copergi 13y ago
>Play's refresh-recompile trigger means it is not meaningfully less productive than PHP Except with PHP you hit refresh and it is done. With play you wait 10 seconds and it is done. There is a huge difference.
- Aqueous 13y ago
  But after you've waited 10 seconds (in my experience, with a single code change it is usually more like 2 - 3 seconds) what you've done has a greater likelihood of working the way you intended, since it wouldn't have compiled at all if your intentions were less well-defined.
  - copergi 13y ago
    Perhaps, but I've already gone back to surfing the web in those 10 seconds. And scala provides pretty poor type safety compared to how bad the compile time is. I don't actually use PHP, I was just pointing out how the claim that play's workflow is just as productive is inaccurate.
- virtualwhys 13y ago
  > Except with PHP you hit refresh and it is done. With play you wait 10 seconds and it is done. There is a huge difference. eh? With incremental builds you should be seeing far more 1 second recompilations than 10 second recompilations. If you're getting 10 second recompiles, the following help: 1) sub projects, it's an absolute must for non-trivial apps 2) use a 3rd party build system (say, GruntJS) for assets Also, be sure to ;clean;compile prior to starting an incremental build with ~run (and of course, do this from a play> prompt and not bash, you want a warm JVM)
  - saryant 13y ago
    I do wonder how many compile time complaints are due to restarting SBT every time.
    - virtualwhys 13y ago
onezerozeroone 13y ago
Exactly this. Developers need to think holistically. Sure, maybe you can F5 your way to basic functionality, and that might make it seem like you're saving time in the short-term, but you also need to account for the hours and hours of painful bug hunting you'll occasionally (but inevitably) incur when that one sneaky null reference or fence-post error makes it into prod.

by Aqueous 13y ago

mason55 13y ago

> Not even sure why people need an IDE. For someone learning Play & scala in general I find the IDE to be immensely helpful in showing my type information and valid auto-completes. Rather than constantly digging through documentation I can see that, for example, some flatMap will give me a list of (Id, User) tuples, so then I can call map( case(id, user) => user) ) (or just map(_._2)) and pull out the user objects to get my list of users from my list of tuples. This lets me focus on the business logic and not spend all my brain power tracking types. I don't think I would have survived my first foray into building complicated composite ResultSet parsers in anorm without the IDE. I'm sure that as I gain more experience and all the functions become second nature I'll be able to track it in a text editor but for now I love my IDE.

Aqueous 13y ago
Yes, I edited that statement out - I'm sure people have good reasons for using IDEs, immediate type evaluation being one of them.

ebiester 13y ago

So, how do you write your unit tests? Within grails and guard (and other systems as well), I save my file and I have all the relevant unit tests running immediately. I have less than a second lapse. At least, when I was working within play, it was painful enough to discourage me from test driving my code, especially if implicits were involved.

saryant 13y ago
sbt ~test will run all your tests on file save. sbt ~test-quick will only run previously failed or new tests on file save. On one Play project we have ~160 test cases, including integration tests that spin up real Neo4j and Elasticsearch instances. Running the whole suite takes around 90 seconds. That would be far less if I did a better job separating unit and integration tests or mocking out the external dependencies.
Aqueous 13y ago
I spend most of my time running specs2 - unit specs - from the command line. I'm sure I could have sbt trigger on save but since I save pretty much constantly I'd have the tests running all the time. I will freely admit the compile time on tests is a bit extreme but I've found that it doesn't appreciably slow me down, since I typically run the tests when I'm confident the new code will pass. As for integration tests those run via Specs2/Selenium as well but I rarely run them from my own machine as they are continuously running on Travis CI whenever I push to our repositories.
kasey_junk 13y ago
Not sure about the state of the play framework, but the standard Scala build tool allows you to do the exact same thing as grails & guard using the ~test-quick operation.

kasey_junk 13y ago

I've tried dropping an Intellij several times while programming Scala, but have never figured out a VIM/Shell configuration that gives me what I need. That is: - Type safe re-factorings (why would I give up on my type system to just go grepping around my code base?). To be honest I don't use variable extraction as often in my Scala code as I did in Java, but to have never used it makes me think you are severely undervaluing the whole type safe re-factoring universe. - Automated import statements. - Configurable code formatting. The IDE space is improving dramatically in Scala, but I do think the Scala teams blessing of Eclipse was a mistake. They should have been writing more generic tools/hooks to empower their users in a wide variety of development setups.

hp 13y ago
The current direction we're hacking on is definitely toward shared code between Eclipse and other tools and editors.

copergi 13y ago

>Play's refresh-recompile trigger means it is not meaningfully less productive than PHP Except with PHP you hit refresh and it is done. With play you wait 10 seconds and it is done. There is a huge difference.

Aqueous 13y ago
But after you've waited 10 seconds (in my experience, with a single code change it is usually more like 2 - 3 seconds) what you've done has a greater likelihood of working the way you intended, since it wouldn't have compiled at all if your intentions were less well-defined.
- copergi 13y ago
  Perhaps, but I've already gone back to surfing the web in those 10 seconds. And scala provides pretty poor type safety compared to how bad the compile time is. I don't actually use PHP, I was just pointing out how the claim that play's workflow is just as productive is inaccurate.
virtualwhys 13y ago
> Except with PHP you hit refresh and it is done. With play you wait 10 seconds and it is done. There is a huge difference. eh? With incremental builds you should be seeing far more 1 second recompilations than 10 second recompilations. If you're getting 10 second recompiles, the following help: 1) sub projects, it's an absolute must for non-trivial apps 2) use a 3rd party build system (say, GruntJS) for assets Also, be sure to ;clean;compile prior to starting an incremental build with ~run (and of course, do this from a play> prompt and not bash, you want a warm JVM)
- saryant 13y ago
  I do wonder how many compile time complaints are due to restarting SBT every time.
  - virtualwhys 13y ago

onezerozeroone 13y ago

Exactly this. Developers need to think holistically. Sure, maybe you can F5 your way to basic functionality, and that might make it seem like you're saving time in the short-term, but you also need to account for the hours and hours of painful bug hunting you'll occasionally (but inevitably) incur when that one sneaky null reference or fence-post error makes it into prod.