Hacker News Reader

> Operator overloading seems to be highly encouraged, and library authors go to town with it.

This, the "every single library needs to provide some clever DSL", is my major complaint with Scala. It's not really Scala's fault either, Scala's core libraries don't have this problem. It's 3rd party developers with no restraint. So it doesn't have to be this way and I think (or hope, based on some comments about Scala on this site previously) that it's beginning to become a discouraged practice.

Still, I have an immediate, visceral reaction to it after the years I spent trying to untangle heaps of overly clever C++ code with the same kinds of issues. I never want to be in that situation again.

Code should be, above all, easy to read. If your code looks like a different language depending on which library you're using, that's a real negative.

At least we now have pretty good IDEs that help out, but even then I think that it's probably not be a good sign if you kind of need to have a good IDE to understand the code.

The design approaches for Scala and F# are different though: F# is mostly FP with some OO tackled on - mainly influenced by OCaml. Scala unifies both OO and FP.

> If you know f#, you practically know Scala - well, enough to be instantly productive.

Sure, but actually you can say the same about knowing Java/C# and then moving to Scala. But in that case you're missing a whole lot of features that Scala offers that F# does not: typeclasses, traits, implicits, etc.

True. I was referring to similarities in things like higher-order functions, tail-recursion support, pattern matching, option types and so on.

I feel the intersection of FP features between F# and Scala is much greater than C#/Java.

"F# is mostly FP with some OO tackled on - mainly influenced by OCaml. Scala unifies both OO and FP"

So Scala is mostly OO with some FP tackled on?

In my understanding, it's hard to say. It appears to have a base semantics that you can think through as OO-like message passing or FP-like lambda calculus reduction. I assume it's implemented OO-style on the JVM, but it's hard to say whether the core language biases one side or the other.

I think that's interesting but also a big indicator of why you see such a big split-brain situation in Scala. FPers program FP-Scala, OOers program OO-Scala, but neither is dominating. As far as I can tell, Martin Odersky programs balanced OO-FP, but few others do.

scala is the unholy child of everything from oo and everything from fp (well, almost).

(but i found it hard enough to program in ocaml, which is similar to f#, because i was always torn between oo and fp parts, so maybe i am biased or just Too Dumb For Scala)

I wish that sbt had the ability to work with exploded scala source dependencies, instead of insisting everything work in the JAR world. I am used to working with rubygems/pip and love the ability to go and screw around in the libraries. When I'm ready to package, I can run "sbt assembly" instead and it can take a little longer to build a packaged JAR.

Clojure/leiningen has the same issue (although there are ways to get the source itself as well [1], but nowhere as clean as rubygems).

[1] http://stackoverflow.com/questions/14395413/how-do-i-make-le...

Why do you want this?

Could you elaborate what you mean by "insisting everything work in the JAR world"? SBT works with git submodules, git sources, other URI or File sources for dependencies. So you must mean something else, but I'm having trouble parsing.

Rubygems and Python packages are source packages. When you used the package management tools in those languages, these packages are downloaded to somewhere in your path and used within the code you are writing.

In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org). This is how you share a ruby gem - http://guides.rubygems.org/publishing/#sharing_source_code . I can now specify in my Gemfile to pull a particular branch/tag/version of the gem directly from revision control.

The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place. This is how you share your scala code - http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topic... . Remember, publishing means packaging into a JAR. If you were too lazy to package your code into a jar and publish it ... well, then it's cumbersome to work directly from the repo.

I really, really wish scala/clojure would enable the ability to work directly with source as packages - the big, big reason why it's not is the maven backend.

Seems easy to attach source and javadoc in Maven pom.xml:

http://maven.apache.org/plugin-developers/cookbook/attach-so...

Can't you use maven with your scala project?

Most open source Java lib/framework that publish their JARs to the central Maven repository also publish their Source code and JavaDoc JARs as well. This is where I applaud the Java OSS community.

I'm not sure I understand why this is a problem. SBT, leiningen, maven and pretty much every other build tool on the JVM supports publishing source jars. I think SBT even does it by default. Nearly all of the open source projects I have worked with on the JVM publish their source jars (Grails used to not but even they do now).

Are you running in to a lot of projects that don't publish their sources?

Also, SBT can use use other SBT projects in github repos as depedencies: http://alvinalexander.com/scala/using-github-projects-scala-...

> In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org).

That's a feature of Bundler, not Rubygems.

> The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place.

I don't follow. I mean, you don't need to setup a local repository anymore than you need to setup a local Rubygems repository.

Checkout this anonymized and trimmed up `build.sbt` for the project I'm currently working on: https://gist.github.com/sam/7162604

It's got a number of JAR dependencies, followed by project references to projects on the local filesystem as well as Github, neither of which are JARs.

In fact, because I don't have much clue how to distribute my own libs on maven.org, I don't bother. If you want to use it, just drop the URI into your build.sbt and away you go.

Is this not what you're looking for?

If you want to create a JAR (say for deployment), and you're not working with a Play application, and you don't want to publish the JAR to a repository, that's cool too. Just run `package`, or use the sbt-assembly plugin. Just takes a couple seconds.

SBT is basically Rake + Bundler + RVM + Guard + RDoc all in one. I'm not aware of anything that those do that SBT can't. It's pretty easy to pick up as well. People complain about it, but I've personally invested a lot less time learning SBT than I have in those tools and feel like I'm probably as proficient at this point.

@ssmoot - this is extremely interesting. Thanks for pointing out RootProject. After doing that, are you able to use them just as seamlessly as declaring it in libraryDependencies. For example, "sbt assembly", etc. work just as fine ?

BTW - I double checked now, your code only works on sbt 0.13. My previous version of 0.12.4 doesnt work with it.

So, I guess it's cool that this kind of stuff is working now!

It works as you'd like yes.

The reason my code is SBT 0.13.x specific is just because .sbt file syntax was robustified in 0.13.x to cover most cases you'd previously need a Build.scala for.

You can do the same thing easily in 0.12.x, it just requires you do it in a Scala class that extends sbt.Build instead. In fact, that's what my code was a few days ago. I only just ported it to the new SBT 0.13.x syntax since the old syntax continued to work. We'd been using 0.13.x for awhile, I just hadn't got around to porting the build from being spread across build.sbt and project/Build.scala to consolidating to just the build.sbt.

The docs for SBT are actually really thorough, but to me at least, a bit hard to get into. I blame the theme at http://scala-sbt.org and the fact that there's no obvious "from basics to mastery" guide. The website feels more like a manual. Going deeper than you might want pretty quickly, but before you've got the breadth of it down. If that makes any sense?

That said, if you end up having to work with SBT for your day-job, you end up picking everything up pretty quickly once you're forced to. It's a lot more consistent than anything on the Ruby side. You may have a few syntaxes to choose from to add a libraryDependency for example (single, Seq, special operator), but the mechanics are all the same and directly exposed to you. You're building a definition for the build, not actually performing work, so as long as that dependency sequence ends up with the graph it needs you'll get the result you need. There's not a lot of magic to it. Despite peoples complaints about the operators (which honestly, there's only two or three you'll run into regularly, and it's not black magic, just look them up or Command+B in IntelliJ to see what they do).

Can't you just declare those exploded source deps as submodules?

I've only given Scala cursory overviews and haven't written code in it. But when I inspect Scala code, it seems incredibly verbose. I was told that the type system is so powerful, type inference isn't possible in many situations, so you end up type annotating everything. That's one of the things I love about F# - code's far more compact without type annotations. Scala seems like it really wants to embrace Java's OOP completely.

> It's such a relief that whatever you build will run on anything with a JVM. Xamarin/Mono is awesome, but those guys are still a little obscure, and a tougher sell than a JVM-based language.

Yeah, and there are still some unsupported functions and properties in ASP.NET that keep you from being able to just drop an MVC project in. :(

The problem with Xamarin is that it's expensive. Xamarin's docs don't really explain how big a project can get before you need to pay for expensive licenses, but I can't advocate at my company for a license that expensive when we're developing Scala pretty much for free.

I haven't tried Idea for Scala recently (last time I tried it was much worse than Eclipse), but incremental compile in Eclipse is so fast that I basically do not notice it. Or were you talking about full compile times? These are rarely needed.

Scala support in IDEA is great right now. I think it's better than Eclipse at the moment, although my experience with Eclipse was observing over my coworkers' shoulders.