Hacker News Reader

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.

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!

Scala's creator's course on coursera certainly doesn't encourage complicating things beyond the minimum necessary

https://www.coursera.org/course/progfun

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.

I resent Scala because it takes up a spot in the JVM ecosystem that I wish a ML family member would occupy.

I really hope Java 8 will slow down Scala's growth.

I really wonder why we need the JVM at all.

For Haskell at least, the GHC runtime is getting pretty good, and seems to have at least basic tools for GC analysis etc. I'm ignorant of MLs so perhaps someone can speak to their status.

Of course there's the much-touted "Java Ecosystem" but it's looking crustier than ever methinks. Maven?? Blech! Also, it doesn't seem wise anymore to build a website on Servlets/JSP/SpringMVC etc, esp. if you want to attract devs. Rest APIs maybe.

What's the killer feature these days recommending the JVM?

Reliability, performance, maturity, instrumentation, diagnostics.

Just picking one example from the list, performance: How is GHC's runtime dealing with 100GB+ heaps?

Do the Oracle or OpenJDK JVMs deal well with heaps that large? I have no interest in other JVMs because my employer would not consider switching and I can't say I blame them.

It depends on what you mean by "deal well with heaps that large". You can certainly set them that large with no problems. But given your memory patterns they can cause dramatically bad GC times.

Yes. It's routinely done.

I'm not sure what libraries you could be talking about except the Twitter ones, which yeah, are slow, don't use them.

There really are a bunch of new features and a faster development pace than Java; look at the differences between 2.11 and 2.9 (e.g. macros).

I enjoyed Dr Ordersky's course (of course, it's based largely on SICP, which I also enjoyed), but there's a world of difference between the code you write for those exercises and the code you write in the real world.

I'm on record as being a Scala skeptic; I've already run into things that the type system seems to encourage but causes headaches, and the size of the language means that no matter how small a subset you write yourself, you can't help but page out when someone else's subset is different than yours. I know that C++ or Perl wizards eventually get to the point where this isn't a problem, and I guess that Scala is positioning itself as Java++, so the same caveats apply.

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.

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.

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.