Live data from Hacker News

Choosing Scala

teaching.software-carpentry.org

41–50 of 65 posts

Re: Choosing Scala

#41
post #26

As a software engineer I find Scala to be a very powerful tool, but one which takes some time to learn. I could see it being a useful teaching tool if they stay away from obscure corners of the language. I'm glad that they didn't go with Java, but I'd only go with Scala if the students are a sharp bunch. Python would also have been a suitable choice.

> "I'm glad that they didn't go with Java" 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.

My university switched from Java to Scheme (Racket) for their first year language.

I'm not sure why they're trying to scare the poor first years away.

Re: Choosing Scala

#42
post #39
post #32

I don't come from a CS background, but I have been programming professionally many years and recently got started with Scala. I had tried Go before and I like Go. I also really like Scala. 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,…

Having worked with Scala for the past almost two years, I can tell you this: you're missing out by not using IntelliJ. It is a huge timesaver, not just from the code completion or the inspections, but also by being able to fire up FSC outside of IntelliJ and have your code recompile very, very quickly when you make changes. The one thing that IntelliJ doesn't do very well yet is work with sbt. It works, sure, but the…

> being able to fire up FSC outside of IntelliJ and have your code recompile very, very quickly when you make changes

I guess that you can achieve the same benefits with an always-open SBT console.

I usually do

  ~ test
So SBT will recompile and launch test after every :w in VIM

Re: Choosing Scala

#43

Earlier quoted context omitted.

Well, why? 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 differen…

The thing is, it's not just an overload; it's an overload and a typecast. Those are two separate questions, and OP is really complaining about the typecast, not the overload. 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 i…

> it's an overload and a typecast.

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.

Re: Choosing Scala

#45
post #43

Earlier quoted context omitted.

The thing is, it's not just an overload; it's an overload and a typecast. Those are two separate questions, and OP is really complaining about the typecast, not the overload. 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 i…

> it's an overload and a typecast. 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.

You start with an integer and end up with a string. The intermediate steps required to get from one to the other aren't particularly relevant to the point I was making.

Re: Choosing Scala

#46

I really want to understand what the fuss is about with Scala so I fired up a REPL and found a tutorial and went to work. Then I can across this: scala> print("5" + 5) 55 And I stopped there (for now). At least my C++ compiler will warn about that (although it will still compile even if it doesn't print anything save for the newline): #include using namespace std; int main(int argc, char *argv[]) { cout Python gives…

The problem is that you don't understand Scala operators. There are none. That + sign there is simply the name of a method in the class of the object preceding it. 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…

    scala> 5 + "5"
    res0: String = 55

Re: Choosing Scala

#47

Earlier quoted context omitted.

Scala inherits essentially all its expression syntax from Java, including the string +. This was done because a lot of other things in Scala are new, so we did not want to rock the boat too much with changes that might seem arbitrary. That said, I believe string + is probably the most criticized feature in Scala's expression syntax. People are generally moving away from it, towards String interpolation, which is avai…

Thanks for joining the discussion. Just want to say I'm working through the the videos for your coursera course ( https://www.coursera.org/course/progfun ) and, in addition to being a great introduction to Scala, it's changing how I approach other functional languages like JavaScript and R

At most JavaScript is an imperative language with functional flavour

Re: Choosing Scala

#48

Earlier quoted context omitted.

Well, why? 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 differen…

The thing is, it's not just an overload; it's an overload and a typecast. Those are two separate questions, and OP is really complaining about the typecast, not the overload. 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 i…

Some things to note:

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.

Re: Choosing Scala

#49
post #32

I don't come from a CS background, but I have been programming professionally many years and recently got started with Scala. I had tried Go before and I like Go. I also really like Scala. 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,…

> With Scala I've already bought 3 books, and have bookmarked nearly 100 sites.

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,

Re: Choosing Scala

#50
post #37

I really wanted to like Scala, I came to the language looking for a Haskell on the JVM, but then just found it sacrificing too much, mainly for Java compatibility. 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 dev…

You call it sacrificing, I call it awesomeness. Scala achieves the best marriage between OOP and FP available. If you come from Haskell, you can view that as a sacrifice, of course. But I don't, to me that's a strength.

Scala is not Haskell and Haskell is not Scala. If you use one and expect the other, you'll be disappointed.

Post reply on HN