5 ms·

Saw some Scala at a conference recently. The guy was demonstrating using it to do TDD. I lost track somewhere in the first ten minutes or so, but it looked lik

Saw some Scala at a conference recently. The guy was demonstrating using it to do TDD. I lost track somewhere in the first ten minutes or so, but it looked like he was importing/using multiple DSLs and helper libraries. After I lost track of the exact details, I started scanning for the gist of what he was doing. After an hour, he had what looked like the most massive clusterfuck I've ever seen in a project file -- all to do something that would take a dozen lines or so of simple FP script. Seemed like every functional thing he used was either also an object or had to be bolted into an object graph for it to work. The project file had scores of things in it. This did not leave a good impression. It reminded me of when I saw my first C/Win32 app and realized you needed a couple hundred lines of code and several files just to say "hello world" -- except this was a couple orders of magnitude more complex. It was a god-awful abomination. Hopefully Scala projects are not like this.

lmm 12y ago
Not all Scala projects are like this. There's a sect that wants to write tests in "human readable" fashion, e.g. the people who like Cucumber in Ruby; in Scala those same people write their DSLs within the language, something Scala is good at and that I'd argue provides real advantages over an "external" DSL. But you don't have to do that; I write Scala professionally and all my tests are just ordinary JUnit test methods.
- DanielBMarkham 12y ago
  Whew! I'm okay with using DSLs. Hey, if you have good FP, flaunt it. My concern after watching this, however, was whether or not the JVM development environment itself encourages complicating things beyond the most minimum thing needed to solve a problem when you're using it in a functional manner. (I haven't done Java in a decade). So, for instance, could I have just written a simple 12-line script to solve the problem he was banging around? Or would I have to create some kind of object with a "main" method? Could I just add in a test file and write functional tests from there, aka JUnit, or do I have to bolt something in that then requires a separate project structure and so forth (aka JUnit) There's no right or wrong answer for any of these types of project configurations. Heck, I like my tests in a separate project. It just looked like every time he had a new need, the project got 14 times more complex. The solution to one problem made the entire development environment more complicated for everything else. That's heading in the wrong direction, no? Admittedly I only had a brief glance. Thanks for the answer!
  - lmm 12y ago
    You still have to put code inside an object, but it's two lines of boilerplate rather than Java's 8 or so: object MyApp extends App { code here } I tend to use Maven to build my projects, so test classes have to go in src/main/test, have names ending in Test, and have their test methods annotated with @Test. But there's nothing to stop you making another App that just runs tests when it's executed, if you want to do that. Things should be orthogonal, and that's usually something Scala is very good at, e.g. the way (scalaz) Futures are handled is IMO a very elegant balance between exposing the difference between sync and async code and not making it too cumbersome to use.
  - benwaffle 12y ago
    Scala's creator's course on coursera certainly doesn't encourage complicating things beyond the minimum necessary https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun
    - orteipid 12y ago
      I've used Scala on and off professionally for about 4-5 months and the best advice I could ever give to someone using it for the first time is to try and treat it like Ruby but with type safety. As numerous people before me have said, the language is a mess. Although it offers some benefits, the syntax is so absolutely bloated that you're probably better off taking the time to really consider whether or not you absolutely need it for all of the headaches and unreadability you're going to run into in terms of code. There aren't many Scala developers out there and the learning curve can and likely will punish you when things need to get done, assuming you're bringing in new developers. The open source libraries all generally seem to have glacially slow development processes, which in some cases might be considered acceptable, but when the main Scala team pushes out 2.11.x (and to some degree actively encourages its use) and X framework you're using literally cannot run because library Y is not compiled against it, you end up stuck on Scala 2.9/2.10 which is really unpleasant for you because you're missing out on the speed increases and other quality of life improvements (how many times have you run into the 22 argument limit for case classes on 2.10?). Perhaps I'm asking for too much, but Scala strikes me as a language that's supposed to be moving a bit faster than Java in terms of development, but that doesn't really seem to be the case. All in all, while it has some neat parts, if I never got to work with it again I wouldn't be crying about it.
ssmoot 12y ago
Scala is going to be generally more concise than Ruby (which I think most consider fairly concise). So the impression I get from your comment is that this was a fairly large and/or complex project he was attempting to demonstrate. Maybe it just wasn't real appropriate.
yummyfajitas 12y ago
Here is some actual test code, based on scalacheck: property("to and from file") = forAllNoShrink(genArrayForSeries)( data => { withTempDir(f => { val (stagingDir, dataDir) = mkdirs(f) val s = SequentialBinaryV1Storage(dataDir, stagingDir) val id = SeriesIdent(UUID.randomUUID().toString) val oldSeries = BufferedSeries(id, data._1, data._2) s.write(oldSeries) val newSeries = s.read(id).get ((oldSeries.ident == newSeries.ident) :| "identities do not match") && ((oldSeries.data == newSeries.data) :| "data series do not match") }) }) Not much DSL, though there are a few helper functions handling stuff like creating a tempdir for the test and deleting when finished.

lmm 12y ago

Not all Scala projects are like this. There's a sect that wants to write tests in "human readable" fashion, e.g. the people who like Cucumber in Ruby; in Scala those same people write their DSLs within the language, something Scala is good at and that I'd argue provides real advantages over an "external" DSL. But you don't have to do that; I write Scala professionally and all my tests are just ordinary JUnit test methods.

DanielBMarkham 12y ago
Whew! I'm okay with using DSLs. Hey, if you have good FP, flaunt it. My concern after watching this, however, was whether or not the JVM development environment itself encourages complicating things beyond the most minimum thing needed to solve a problem when you're using it in a functional manner. (I haven't done Java in a decade). So, for instance, could I have just written a simple 12-line script to solve the problem he was banging around? Or would I have to create some kind of object with a "main" method? Could I just add in a test file and write functional tests from there, aka JUnit, or do I have to bolt something in that then requires a separate project structure and so forth (aka JUnit) There's no right or wrong answer for any of these types of project configurations. Heck, I like my tests in a separate project. It just looked like every time he had a new need, the project got 14 times more complex. The solution to one problem made the entire development environment more complicated for everything else. That's heading in the wrong direction, no? Admittedly I only had a brief glance. Thanks for the answer!
- lmm 12y ago
  You still have to put code inside an object, but it's two lines of boilerplate rather than Java's 8 or so: object MyApp extends App { code here } I tend to use Maven to build my projects, so test classes have to go in src/main/test, have names ending in Test, and have their test methods annotated with @Test. But there's nothing to stop you making another App that just runs tests when it's executed, if you want to do that. Things should be orthogonal, and that's usually something Scala is very good at, e.g. the way (scalaz) Futures are handled is IMO a very elegant balance between exposing the difference between sync and async code and not making it too cumbersome to use.
- benwaffle 12y ago
  Scala's creator's course on coursera certainly doesn't encourage complicating things beyond the minimum necessary https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun
  - orteipid 12y ago
    I've used Scala on and off professionally for about 4-5 months and the best advice I could ever give to someone using it for the first time is to try and treat it like Ruby but with type safety. As numerous people before me have said, the language is a mess. Although it offers some benefits, the syntax is so absolutely bloated that you're probably better off taking the time to really consider whether or not you absolutely need it for all of the headaches and unreadability you're going to run into in terms of code. There aren't many Scala developers out there and the learning curve can and likely will punish you when things need to get done, assuming you're bringing in new developers. The open source libraries all generally seem to have glacially slow development processes, which in some cases might be considered acceptable, but when the main Scala team pushes out 2.11.x (and to some degree actively encourages its use) and X framework you're using literally cannot run because library Y is not compiled against it, you end up stuck on Scala 2.9/2.10 which is really unpleasant for you because you're missing out on the speed increases and other quality of life improvements (how many times have you run into the 22 argument limit for case classes on 2.10?). Perhaps I'm asking for too much, but Scala strikes me as a language that's supposed to be moving a bit faster than Java in terms of development, but that doesn't really seem to be the case. All in all, while it has some neat parts, if I never got to work with it again I wouldn't be crying about it.

ssmoot 12y ago

Scala is going to be generally more concise than Ruby (which I think most consider fairly concise). So the impression I get from your comment is that this was a fairly large and/or complex project he was attempting to demonstrate. Maybe it just wasn't real appropriate.

yummyfajitas 12y ago

Here is some actual test code, based on scalacheck: property("to and from file") = forAllNoShrink(genArrayForSeries)( data => { withTempDir(f => { val (stagingDir, dataDir) = mkdirs(f) val s = SequentialBinaryV1Storage(dataDir, stagingDir) val id = SeriesIdent(UUID.randomUUID().toString) val oldSeries = BufferedSeries(id, data._1, data._2) s.write(oldSeries) val newSeries = s.read(id).get ((oldSeries.ident == newSeries.ident) :| "identities do not match") && ((oldSeries.data == newSeries.data) :| "data series do not match") }) }) Not much DSL, though there are a few helper functions handling stuff like creating a tempdir for the test and deleting when finished.