Choosing Scala
teaching.software-carpentry.org
teaching.software-carpentry.org
Scala requires much more work to learn than Go. I don't think I ever ventured out much from the offical Go documentation, the spec and effective Go and the library documentation to learn Go. With Scala I've already bought 3 books, and have bookmarked nearly 100 sites. I frequently have very many tabs opened with various scaladocs, examples and stackoverflow questions open.
My favorite thing in Scala is Akka. I quite like Akka and I like the functional programming that's possible with Scala. The build tools, like sbt require getting used to but I'm able to pretty much get along just fine without an IDE. I do have intellij open but I hardly look at it. I do all coding in vim and testing with sbt.
About 14 days in and I can connect to TCP and parse JSON ok. That's where I'm at. There have been some pretty frustrating moments, mostly dealing with 3rd party libraries (like scalaz, not documented much) and sbt, but once overcome it feels rewarding.
My other favorite things in scala: it has a REPL, s"String $interpolation" and pattern matching.
I've also written a blog post about learning resources. Maybe it helps you: https://www.bionicspirit.com/blog/2013/05/13/getting-started...
As a word of warning, don't use Scalaz while in the learning process. It's a pretty cool library, but I've been developing with Scala for the past 2 years already and personally I've never felt the need for Scalaz.
Akka is great, the standard library is great, Play is great. You can also use any Java library you want and wrapping Java libraries in Scala-ish interfaces is great for learning ;-)
> Scala requires much more work to learn than Go.
This is true. Go is more familiar because it has a less complicated (and unfinished) type system and because it doesn't contain too many unfamiliar concepts to developers that are used to mainstream languages.
For example in Scala you end up seeing a lot of flatMaps() being used on monads, you also see type-classes or persistent/immutable data-structures, or the CanBuildFrom pattern which looks intimidating at first, but it's actually rather nice. Scala's type system is also much more static and more expressive than that of Java, Go or C# and I'm specifically talking about generics. Scala makes it easier to write statically type-safe generic code, so of course, people end up wanting more and some of them go crazy with that.
Being a static functional programming language, the type system is intimidating at first, but as you learn about it, you'll see that it's elegant and much thought went into designing it. And most importantly, it helps you to write better code, instead of just staying in your way.
Scala also contains simplifications versus other mainstream languages. In comparison with C# or Java, in Scala there is no such thing as static methods or members. In fact, in Scala all member accesses are considered method calls. This has great implications for polymorphism. In comparison with other languages that mixed OOP and FP (e.g. F#, Ocaml), in Scala all types are modelled by means of classes or traits. While using other languages, you'll notice that OOP (sub-typing) is a pain in combination with generics because covariance/contravariance is a bitch to deal with. Java's generics are broken, because at the class level they simply don't deal with it (they preferred invariance) and then for the methods themselves you've got to use wildcards. Scala is much saner in that regard. It also has a unified access philosophy that really simplifies things and the marriage that it achieves between OOP and FP is really good. In my opinion, only Clojure's protocols are on the same level while being somewhat simpler, but that goes with the territory of a dynamic language.
Anyway, Scala's learning curve may seem intimidating, but (1) it's worth it because you learn a lot about FP with Scala (the ML style, not the LISP style, which is slightly different :)) and (2) you don't need to use advanced concepts to write working code.
Have fun,
I guess that you can achieve the same benefits with an always-open SBT console.
I usually do
~ test
(Advice for understanding scalaz: look at the type signatures. Try and implement a function with that type signature yourself. In fact, the first few times I find it's best to write the thing without using scalaz myself, then notice that part of it has a type signature that matches a method in scalaz, and then replace that with the scalaz method.)
Although I like Haskell and FP, this is one of the reasons that I have been very hesitant using Scala in my previous or current position, although both were Java/JVM-heavy. Using Scala has the implication that some of my colleagues have to learn it as well, and learning FP and Scala well can be a multi-month or multi-year project.
With a language such as Kotlin, one can scrap much of the Java boilerplate, while most of it is very easy to pick up for a Java programmer in a few days or weeks.
That said, Typesafe are doing great work! I use and love Akka and it works great in Java as well (if you don't need to compose futures to much :^)).
A very short summary of my impressions from Scala: * It is beautiful, I felt the half-forgotten beauty of functional programming once again
* Scala worksheets (quick scratch to evaluate whole code snippets with immediate feedback) are awesome. I love them even more than REPL (Then again, I love IPython notebook more than Python REPL too)
* Scala seems a bit heavy in terms of number of concepts
* Scala can be terse and very expressive, but pretty verbose if you need it to be
* Compilation of large programs is slow and eats gobs of memory
* tail-call optimize everything
* (Mostly) Python-ic syntax (indentation-based)
* Type inferance
* OOP (but only when you want it)
* Good expressivity
* Compiles via c (FAST, easy linking with C libs, no runtime required, prodoces standalone binaries)
* Lean core (Not a "kitchen sink" language, but has good support for FP and OOP)
The close compatibility with Java does allow an easy transition for Java developers, but it's a transition to writing what it repeatedly deemed unidiomatic Scala by the Scala community. And then I've seen the same community scoff at unenlightened Scala developers that are writing "Java++".
Half of Scala could make a really nice language, but the complexity of the full thing is not something I want to work with again.
Scala is not Haskell and Haskell is not Scala. If you use one and expect the other, you'll be disappointed.
That School (Aalto University) has used Java as a first year language for quite some time. Then they switched to Python (I think), and then to Scala. Before Java, it was Scheme. Before Scheme, I don't know.
I'm not sure why they're trying to scare the poor first years away.
I think the OP really nails the reasons Scala makes sense as an intro language. Students can start with simple concepts and gradually see how these lead to the complicated stuff.
scala> print("5" + 5)
55
#include <iostream>
using namespace std;
int main(int argc, char *argv[]) {
cout << "5" + 5 << endl;
return 0;
}
What's the reasoning behind this in Scala?
JS semantics are those of a functional-oop language. It lacks a few standard functions (LiveScript has prelude-ls) and a ton of syntactic support for things. Once these are in place, you can write the code which looks and feels like Ocaml.
For example, moment.js function is `moment(dateString, formatString)`. In LiveScript I used it as:
parseDate = (flip moment) "DD/MM/YYYY"
(The only really lacking feature in JS is of course TCO, but then Clojure, so yeah, let's just trampoline everything.)
scala> "5" + 5
res0: java.lang.String = 55
> Python gives me a TypeError. And so does Common Lisp. I was expecting the same from Scala
scala> val i:Int = "5" + 5
<console>:7: error: type mismatch;
found : java.lang.String
required: Int
val i:Int = "5" + 5
^
scala> math.max("5" + 5, 5)
<console>:8: error: overloaded method value max with alternatives:
(x: Double,y: Double)Double <and>
(x: Float,y: Float)Float <and>
(x: Long,y: Long)Long <and>
(x: Int,y: Int)Int
cannot be applied to (java.lang.String, Int)
math.max("5" + 5, 5)
^The C++ behavior is notably worse, though: "5" + 5 in C++ is undefined behavior, and will give you a pointer to some mystery data.
I only meant to illustrate that even in C++ where types have a different meaning I will get a warning with a decent compiler.
In either case the expression in both languages garners a silly result. However Scala is happy with the result and reports nothing wrong with it (not even a warning). I was just surprised is all.
"5" + 5
What I think is silly is that, to my knowledge, Scala won't warn you that the result of interpreting this expression is ambiguous and their chosen implementation might not be what you had expected.
A decent C++ compiler will warn you (by default) that adding arrays of bytes to integers doesn't make sense and you are probably making a mistake somewhere. A lesser one will let you opt-in to receive warnings. A poor, silly compiler will just compile it without warning and let you figure out its strange result on your own.
So you invoked print("5".+(5))
What else would you expect. The nice thing about Scala is that you can leave out some of the extra syntax that is not needed for the compiler to decode the meaning.
Now as for why the String class has a + method to do string concatenation? I don't know but this is far from the first language that I have come across that conflates string concatentation with numeric addition. Maybe it comes from the Java libraries? In any case, it is not really a problem to most people because we follow the maxim, if it hurts, DON'T DO THAT!
scala> 5 + "5"
res0: String = 55And I don't want a warning, I want a huge fatal end-of-the-world big red flag error message blinking on my screen until I fix it.
I mean, I'm so used to work in Java which has the same behaviour, so I may have been totally unable to see the problem due to the familiarity of that code, maybe, but I still don't understand the problem.
First, let state the basis: the meaning of the + operator is overloaded. For numeral types, it makes the sum of the operands. For string, it concatenates them. These are two different meanings in different context.
For the numeral types, it will not protest if you sum up a float with an int (and I think most programming languages won't either). The rules of the language are quite clear: the int would be coerced to a float, then the two float be added, and a float will contain the result.
For the string operation, you could force the operands to have all the same types, but you could also practice the same kind of coercion: convert everything (yes, it works for every object of any sort) to a string, then concatenate.
OK, it may be odd mathematically, but let's see it for what it is: a very handy syntactic sugar in the form of an overloading of the meaning of +, which obey simple rules, and thus have no potential to mean something else than what the programmer meant.
The ints vs. floats thing is kind of a red herring. In that specific case, at least you're still talking about numbers. The argument against having contagion for 5 + 5.5, and overloading for "5" + "5.5", but throwing an exception for "5" + 5.5 is that the first is a pair of numeric types, the second is a pair of strings, but the third is a pair of unrelated types. You can say white is lighter than black, and a feather is lighter than an anvil, but you can't say that white is lighter than an anvil because that's nonsense.
Incidentally, this is why, say, Python and Ruby (and I imagine Lisp) people insist upon the distinction between dynamically typed and weakly typed. If I fire up a node.js repl, I find that '50' + 5 is '505', but '50' - 5 is 45, and am reminded why JavaScript drives me nuts. In the extreme you get things like [this](http://phpmanualmasterpieces.tumblr.com/post/33198366857/lay...) and [this](https://www.destroyallsoftware.com/talks/wat). I realize that Java probably doesn't do anything near that bad, but the point is that it's a question of balancing convenience vs. error prevention, and that we're talking about a very strictly-typed language which will naturally attract people who tilt toward wanting the error detection, and even dynamic languages that swing the other way on most things often find that you don't need to make your math operators cast numbers into non-numeric types (and risk the resulting runtime errors) to have convenient string handling.
In fact, I think Ruby's string interpolation is actually a better syntatic sugar than Java's `+` cat overload. Consider that I want to print a string along the lines of "1 + 5 = 6" but with arbitrary integers. Here's how it might look in Ruby:
puts "#{x} + #{y} = #{x+y}"
Python 3 is less pretty, but still reasonable:
print("{} + {} = {}".format(x, y, x+y))
print(x, "+", y, "=", x+y)
> have no potential to mean something else than what the programmer meant
is just false. There is a very obvious way for it to mean something other than what the programmer wanted: When the programmer forgot to cast a string to a number and tried to add it to a number. This is particularly a risk in dynamic languages or those using type inference (it's harder to pull off in languages where you have to explicitly declare all your variable types, which may make it a non-issue in Java speficially).
I think you're mixing casts and conversions. At least in the parlance that I'm used to, you can only cast a number to a String or a String to a number in a memory-unsafe language (and it's rarely what you want and a bit dangerous). When you do this, the system will take your word that the data is actually a String and interpret those literal bits in memory as one. In a memory-safe language, this cast would, of course, likely raise an exception. In Scala, you can cast any object to any type with that object's asInstanceOf method.
In Scala (and many other languages), you can convert numbers to Strings and back. In fact, any object can be converted to a String via that object's toString method (which every object has as a quirk inherited from Java). Strings can also be converted to numbers via toX methods (e.g. toInt, toFloat, etc.). Of course, these conversions will raise exceptions if the content of the String does not match the format of the numeric type you are converting to.
This all matters because it is how the + method on String works: it doesn't (unsafely) cast its argument to a String. Rather, it (safely) converts it via its toString method. You may dislike the idea this method exists (I certainly do, and wish it could be deprecated now that Scala has String interpolation), but it is just a method that happens to be defined on the standard library's String type and not a major defeat of the type system.
No, in Scala there is no typecast in that example. Everything is an object in Scala and the + method in String class accepts an object as parameter.
There is some auto-boxing happening under the hoods but that is not type-casting.
Just don't mistake a bad API for some kind of belief that Scala in general idly converts between types. The weakest point is APIs that use methods defined in java.lang.Object (e.g. toString and equals); they can universally use these methods without restricting the type.
Note that if you define a type as a knowledge of what actions can be performed on an object, then no type safety has been lost; toString() is universally available, though it may not do exactly what you want.
scala> println("5" + 5 + 5)
555 scala> val pi = "pie!"
pi: String = pie!
scala> println(f"Care for some $pi%f?")
<console>:9: error: type mismatch;
found : String
required: Double
println(f"Care for some $pi%f?")
^
scala> val pi = Math.PI
pi: Double = 3.141592653589793
scala> println(f"Care for some $pi%f?")
Care for some 3.141593?
- http://docs.scala-lang.org/overviews/core/string-interpolati...
- read: https://github.com/adriaanm/talks/blob/master/scala-2.10/sli...
psedit: I can't resist one of my favorite f# article http://blogs.msdn.com/b/ashleyf/archive/2012/01/26/hp-35-mic...
also, arrayForth chip emulator : http://blogs.msdn.com/b/ashleyf/archive/2013/09/21/chuck-moo...
I use typesafe stack and it's really, really good.
Scala is fundamentally a pragmatic language - it is about compromise between functional purity and JVM/Java-style (OOP-based) mutation. As such, it's hard to really identify the distinctive features of either because Scala is so liberal in what it allows.
I wonder whether students would be better off learning something like Haskell along with (e.g.) Python or Java. And of course a Lisp of some kind(!).