Comment by Aqueous | Hacker News Reader

Comment by Aqueous | Hacker News Reader

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.

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.

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

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

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

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.

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.

  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.

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.

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.

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

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.

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.

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

I do wonder how many compile time complaints are due to restarting SBT every time.

Good point, there's a lot to learn in Scala land as well as many ways to shoot oneself in the foot, cold JVM is a good place to start, ouch, glacial development ;-)

I was testing with a trivial app, so 1 doesn't apply. There were no assets, so 2 doesn't apply. Ghc is notoriously slow at compiling, and it managed to recompile/reload the equivalence haskell test app in the time it takes to alt+tab and hit refresh.

Got a link to this trivial Play app that takes forever to compile (and the equivalent lightning fast Haskell app), or shall we just take you on your word?

Yes, I keep every test app I've ever written on hand just in case an infamous language_X troll demands proof anytime I mention that I saw the sky once and it looked blue.

Reply on news.ycombinator.com