171–178 of 178 posts
Earlier quoted context omitted.
For comparison Ruby is just over 0.3% and has been flat for four years. It's the overall job market, not just programming jobs so all percentages will be low.
Sure, so this tells us there are about 20 times as many Ruby jobs than Scala ones.
That's less that 4x as many Ruby jobs as Scala ones.
Earlier quoted context omitted.
You can do what we did in my team: decide on a style of testing and stick to it (in our case, I liked WordSpec). With JUnit you can't do this, because there is only one style. I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.
I wouldn't recommend it to newbies at all, because it's using relatively advanced Scala features - implicit conversions to make the operators available, "word word word" style desugaring into method calls. Of course these are things that you have to learn eventually and that have value, but making a newbie learn how they work before they can test anything is throwing them in at the deep end, and having to use a test…
The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". To me, ScalaTest with WordSpec seems more natural than JUnit, and at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
Earlier quoted context omitted.
> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. Sounds horribly magic/incomprehensible. > This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. I don't think the work of doing it in M…
> Sounds horribly magic/incomprehensible How is compiling everything in a given directory any more magic/incomprehensible than any other build tool? > I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done What IDE comes with a 'scala template' out of the box? What if you are not already in the JVM ecosyst…
IntelliJ ships with Scala support doesn't it? And the eclipse-based scala-ide comes with maven support, no? So it's just:
- Install scala-ide
Earlier quoted context omitted.
I wouldn't recommend it to newbies at all, because it's using relatively advanced Scala features - implicit conversions to make the operators available, "word word word" style desugaring into method calls. Of course these are things that you have to learn eventually and that have value, but making a newbie learn how they work before they can test anything is throwing them in at the deep end, and having to use a test…
A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument. The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". To me, ScalaTest with WordSpec seems more natural than JUnit, and at least my own experience show…
What's to understand? You write a method in plain old java, and the framework runs it.
> The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes".
The point of "embedded DSLs" is that they follow the ordinary rules of the host language. Otherwise they're no better than an external config file, Cucumber-style (which some people apparently like, but I find utterly unusable).
> at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
When they make a change to code that breaks a test, and you're not there, how long does it take them to understand what's gone wrong? That's the real test of a test framework, and IME ScalaTest does very badly on it.
Earlier quoted context omitted.
> Sounds horribly magic/incomprehensible How is compiling everything in a given directory any more magic/incomprehensible than any other build tool? > I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done What IDE comes with a 'scala template' out of the box? What if you are not already in the JVM ecosyst…
> What IDE comes with a 'scala template' out of the box? IntelliJ ships with Scala support doesn't it? And the eclipse-based scala-ide comes with maven support, no? So it's just: - Install scala-ide
Even if you do combine those steps, there are still further steps a user would have take after they install everything. You described the set up as just being as simple as "Push the button, choose the scala template, give it a groupId and artifactId, done". However, I don't think it is that simple. As far as I'm aware, no IDE will give you a Scala project with a Maven POM. You can choose to create a 'Scala project' or you can create 'Maven project'. You can't create a 'Maven Scala project'. So you will have to figure out how to add Scala support to Maven manually. Also, you may have to figure out how to let your IDE know that your project is both a Maven project and Scala project.
Earlier quoted context omitted.
A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument. The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". To me, ScalaTest with WordSpec seems more natural than JUnit, and at least my own experience show…
> A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument. What's to understand? You write a method in plain old java, and the framework runs it. > The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". The po…
Yes, when a WordSpec test starts failing, junior devs know how to fix it without my assistance. I haven't noticed any difference in dev effectiveness between ScalaTest and JUnit.
Earlier quoted context omitted.
> What IDE comes with a 'scala template' out of the box? IntelliJ ships with Scala support doesn't it? And the eclipse-based scala-ide comes with maven support, no? So it's just: - Install scala-ide
IntelliJ doesn't have the Scala plugin installed by default. However, that is true that you could combine the 'Install IDE' and the 'Install Scala IDE plugin' steps by installing the Scala IDE. Even if you do combine those steps, there are still further steps a user would have take after they install everything. You described the set up as just being as simple as "Push the button, choose the scala template, give it a…
When you hit "new maven project" you choose a template (archetype). Some of those are already set up for Scala. No?
> Also, you may have to figure out how to let your IDE know that your project is both a Maven project and Scala project.
Scala-ide (or any eclipse-based system with the m2eclipse-scala plugin) will detect that automatically.
Earlier quoted context omitted.
> A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument. What's to understand? You write a method in plain old java, and the framework runs it. > The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". The po…
Let me ask your own question back at you: what's there to understand with WordSpec or Cucumber-style tests? It's just a tool, you just use it as documented... just like you don't need to even look at JUnit's implementation in order to use it. Yes, when a WordSpec test starts failing, junior devs know how to fix it without my assistance. I haven't noticed any difference in dev effectiveness between ScalaTest and JUnit…
To use Cucumber you have to understand a whole new grammar. To use ScalaTest you have to understand relatively obscure parts of Scala (implicit conversions, "word word word" style method calls, by-name parameters, ...) - or else treat it like a config file and learn a whole new grammar. To use JUnit you just write plain old Java/Scala.