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…
Choosing Scala
51–60 of 65 posts
Re: Choosing Scala
#52I 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,…
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 :^)).
Re: Choosing Scala
#53Earlier quoted context omitted.
It's inherited from Java, where adding something and a string will implicitly convert the something into a string. The C++ behavior is notably worse, though: "5" + 5 in C++ is undefined behavior, and will give you a pointer to some mystery data.
The example is merely illustration and not the recommended practice for writing C++! (Can you imagine?) 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…
Re: Choosing Scala
#54I 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,…
(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.)
Re: Choosing Scala
#55Earlier quoted context omitted.
scala> "5" + 5 res0: java.lang.String = 55 Don't use print in the REPL... > Python gives me a TypeError. And so does Common Lisp. I was expecting the same from Scala scala> val i:Int = "5" + 5 :7: error: type mismatch; found : java.lang.String required: Int val i:Int = "5" + 5 ^ You can easily get a compiler error, if you enforce the type. The inheritance of Javas "I'll call .toString on anything" is definitely not s…
Isn't this something that type inference should catch though?
Re: Choosing Scala
#56Earlier quoted context omitted.
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
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"
Now tell me that this doesn't look like functional code :)(The only really lacking feature in JS is of course TCO, but then Clojure, so yeah, let's just trampoline everything.)
Re: Choosing Scala
#57Scala 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(!).
Re: Choosing Scala
#58Earlier quoted context omitted.
> 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.
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.
Re: Choosing Scala
#59Earlier quoted context omitted.
> "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
#60I 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 ne…