21–30 of 39 posts
Earlier quoted context omitted.
Doesn't Play have documentation / API for Java?
Yes it does. But even after knowing some basic Scala, I find it significantly easier to work with Play on the Scala side. It feels more of a first-class citizen. However, this is just my personal opinion.
If you do like Scala, I recommend Martin Odersky's Coursera class. I took it a few years ago and it was great! Really fun and I learned a lot. He is a great lecturer.
One way that Scala does win big is supporting a repl style of development. One great example of this is the Spark repl.
If you live in the JVM world, Clojure (which I use more than any other programming language) and JRuby are also worth a good look.
Checked exceptions make Java 8 lambdas basically worthless.
Play is a Scala project first and foremost.
In .NET as a similar choice, very subjectively , I would pick C# over F#, because: 1) succinct != readable 2) ReSharper and Roslyn IDE support makes a difference 3) there is no work opportunity to learn it 4) learning it in spare time would mean not implementing something else - I would prefer to solve domain problems rather than language AND domain problems
In .NET as a similar choice, very subjectively , I would pick C# over F#, because: 1) succinct != readable 2) ReSharper and Roslyn IDE support makes a difference 3) there is no work opportunity to learn it 4) learning it in spare time would mean not implementing something else - I would prefer to solve domain problems rather than language AND domain problems
This doesn't really make sense to me. C# is oriented towards imperative programming while F# is oriented to functional programming. The style of programming that best solves the problem and fits your teams' expertise should dictate the choice.
Scala for sure. It is a more expressive language that leads to less bugs down the road. Encouraging lots of immutability is huge, as well as a bunch of other benefits. There will be a transition time for non-scala devs, but it should easily pay for itself down the road.
It is a more expressive language that leads to less bugs down the road. Encouraging lots of immutability is huge, as well as a bunch of other benefits. Deja vu. I use to talk just like you. My colleagues would too. I miss Java's verbose-ness. It's hell, but for large codebases and tooling - I wish I had a bottle of JDK 8 right now. I heard a lot of this "prescription"-like talk, it'll buy us a lot X down the road. I…
From my experience, Java while more verbose offers better tooling, standards, documentation and support. Scala certainly is more concise but there is a cost that you will incur later when trying to debug or maintain s large fast moving code base. Sbt blows, ide support for scala is spotty and good luck defining a code convention and standard that you can automatically lint and format. To me it's c++ for the jvm (not…
After switching back and forth between Java and Scala a lot I find that I prefer Scala. I have never used it in teams of more than a few people though.
I would recommend the same thing I recommend to all teams. Mandatory code reviews. Don't think of them as judgement. Think of them as async pair programming.
If you want really bad IDE support you can always cross compile Java and Scala in same project with Maven.
From my experience, Java while more verbose offers better tooling, standards, documentation and support. Scala certainly is more concise but there is a cost that you will incur later when trying to debug or maintain s large fast moving code base. Sbt blows, ide support for scala is spotty and good luck defining a code convention and standard that you can automatically lint and format. To me it's c++ for the jvm (not…
Scala is more flexible (for better or worse) and less verbose (for better or worse). Because of this, it's possible to be much more expressive in Scala and it's possible to be much more terse/obtuse. I like Scala's powerful type system -- I just have a hard time reading most other people's Scala. If you're sure you can get a consistency of style and approach in Scala among your team, sure, by all means. But if you be…
What do people mean when they say "powerful type system"? Does that mean it could potential be a downward spiral where everyone creates their own DSL? I use Ruby on Rails and Django - and in ruby and python, it's interpreted on the fly. How will a type system, let alone a "powerful type system", help improve ruby or python's web apps?
For example, Javascript's type system (such as it is) is not, in my opinion, as powerful as Java's -- since there's no compile-checking and the runtime coerces stuff all over the place and does basically no checking at any point.
Python's is somewhat better: there's runtime-checking, but it's duck-typed -- so you could call some array methods on an instance of, say, "FootballField" just because the FootballField has a "__len__" property and the runtime wouldn't catch it.
Java's type system is a tiny bit more powerful -- the compiler does a lot of checking for you (so you can enforce that a method must take an array or a List), but it's not as flexible (until JDK8, there was almost zero type inference, so you had to be super-explicit everywhere).
Scala's type system is more powerful still; traits allow you to describe similar classes in a duck-typed-esque way (without the classes themselves having to opt-in), and there's really good type inference.
I'm not an expert in Scala, so I could be wrong about some of its features in particular, but that's the sort of thing that I mean by "powerful type system".
From my experience, Java while more verbose offers better tooling, standards, documentation and support. Scala certainly is more concise but there is a cost that you will incur later when trying to debug or maintain s large fast moving code base. Sbt blows, ide support for scala is spotty and good luck defining a code convention and standard that you can automatically lint and format. To me it's c++ for the jvm (not…
I tried ScalaIDE once and I hated it. I've also used the IntelliJ plugin for Scala and it was a pleasant experience. Would you explain what you're missing with the IntelliJ plugin?