Live data from Hacker News

Scala School

twitter.github.io

151–160 of 178 posts

Re: Scala School

#151
post #109

Earlier quoted context omitted.

There are certainly poor libraries and bad advice going around (why people tell beginners to use SBT or ScalaTest is beyond me), but that happens in every language. IME the average quality on maven central is if anything better than on PyPi/rubygems/npm/etc., and the IDEs/profilers/debuggers are better than anything you can get for the other languages.

I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE. Also, if you use SBT through Activator[1] you get project templates and an automati…

> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file.

Sounds horribly magic/incomprehensible.

> This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE.

I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done.

Re: Scala School

#152
post #135

I was learning Scala at one point. I was reading Atomic Scala [1] (I'm a big fan of Bruce Eckel as I learned Java from one of his earlier books, and some C++ before that). And I also took the Coursera Course from Martin O on functional reactive programming with Scala. I don't remember what is was actually called... I'm still into alternative languages that run on the JVM...however I went and learned Go Lang in a week…

Don't let your experience with Apache Groovy put you off upgrading to a new JVM language. I learnt Clojure after using Groovy for a few years -- Groovy 1.8 was the last version I used. I then looked at Haskell, and now I'm using Go.

Re: Scala School

#153
post #150
post #129

Earlier quoted context omitted.

Out of curiosity, what's wrong with ScalaTest? I particularly like the WordSpec style, which is easy to write and looks newbie-friendly. It's true SBT is not suitable for beginners. Regrettably, neither is Maven. I don't know which tool is...

I find it makes tests much less comprehensible (and gives them worse IDE integration) than JUnit; it uses gratuitous operator overloading style with e.g. "should". And for a beginner it doesn't really offer any advantage - if you're using generators or the like I can see it might be helpful, but for basic unit testing I find straightforward code with JUnit is much easier.

Using the natural language style assertions is optional though, and only work if you incorporate the 'Matchers' trait in your tests. If that's too magical, you can still use plain old assertions or one of the other styles here http://www.scalatest.org/user_guide/using_assertions

Re: Scala School

#154
post #149

Earlier quoted context omitted.

With more than 2,000 people in its Slack channel alone, I think Kotlin is a bit more than marketing hype (to compare, Java has about 500 and Scala 450). As for your other point, tying Java interop with existential types is pretty absurd. I'd say both Kotlin and Scala are about equally good when it comes to interoperating with Java.

> With more than 2,000 people in its Slack channel alone, I think Kotlin is a bit more than marketing hype (to compare, Java has about 500 and Scala 450). So do you really think Kotlin is used 4x as much as Java? Or is it possible that this is a pretty poor measure of actual usage? > As for your other point, tying Java interop with existential types is pretty absurd. Only as absurd as Java. Java libraries contain met…

> Java libraries contain methods that return existential types (e.g. List) everywhere.

I don't know what libraries you are looking at but these are extremely rare these days. At least for the popular ones. You seem to be talking about Java like it was written eight years ago.

Re: Scala School

#155
post #7

Learning Scala is such a pain. Either you follow a large book completely and master it across several months/years or go through overly complicated online guides and get discouraged. I understand it's a large, advanced language, but the community has to seriously work on making things a bit easier for beginners like me. Just look at how easy it is to learn Go or Rust, their official tutorials are amazing and free on…

Really? Rust was harder for me to adjust to by far. It seems like a moving target and the documentation I found was still lacking.

I would be interested in hearing about what parts of the docs are a pain for you, if you have the chance.

Re: Scala School

#156
post #149

Earlier quoted context omitted.

> With more than 2,000 people in its Slack channel alone, I think Kotlin is a bit more than marketing hype (to compare, Java has about 500 and Scala 450). So do you really think Kotlin is used 4x as much as Java? Or is it possible that this is a pretty poor measure of actual usage? > As for your other point, tying Java interop with existential types is pretty absurd. Only as absurd as Java. Java libraries contain met…

> Java libraries contain methods that return existential types (e.g. List ) everywhere. I don't know what libraries you are looking at but these are extremely rare these days. At least for the popular ones. You seem to be talking about Java like it was written eight years ago.

I gave List as a simple example; usually we're talking about List or similar. Anything that involves a ? anywhere is an existential type, and they're the only way to write a whole lot of things safely, e.g. any kind of callback has to involve a "? super" type to avoid disallowing perfectly valid code. Unless the Java community has abandoned generics and decided to go back to using casts everywhere there's really no alternative in the language.

Re: Scala School

#157
post #150

Earlier quoted context omitted.

I find it makes tests much less comprehensible (and gives them worse IDE integration) than JUnit; it uses gratuitous operator overloading style with e.g. "should". And for a beginner it doesn't really offer any advantage - if you're using generators or the like I can see it might be helpful, but for basic unit testing I find straightforward code with JUnit is much easier.

Using the natural language style assertions is optional though, and only work if you incorporate the 'Matchers' trait in your tests. If that's too magical, you can still use plain old assertions or one of the other styles here http://www.scalatest.org/user_guide/using_assertions

Everything is optional, which is a nightmare for consistency. Using JUnit there's only one style of testing and every test follows it.

Re: Scala School

#158

Earlier quoted context omitted.

I've taught Scala to tens of engineers. The golden path is the Coursera course "Functional Programming Principles in Scala"[1]. It's a pretty comprehensive set of lessons, by the author of the language, of how to tastefully compose the basic elements of Scala to solve interview-sized questions. I really think that Martin Odersky's skill as an educator is a highly underrated part of the success of the language. [1] ht…

I'm curious - is the harder part of learning Scala the language itself, or getting one's mind around functional programming itself? (Does having a Scheme/LISP background help?)

For me, I grasped most of usage of the language fairly quickly, from a standpoint of working functionally. I think there are a couple parts of Scala that are intimidating to beginners.

First of all, there's a lot of choice in how to organize a solution to a given problem. Say you've just started to grasp the idea of algebraic data types and manipulations thereof. You might still find it hard to know how to apply it in a given situation, because there are several ways to do it [1]. As you gain experience, you start to get a feel for which option is more appropriate in a given situation.

Secondly, a lot of the basic concepts of Scala are super general, so you can sometimes see language elements used in ways that are surprising. In my experience, you start to build a mental model for actual usage of language elements, but it's still intimidating at first. See this question and answer about the `object` keyword [2].

But then, even as you master the language, there are all sorts of little gotchas you learn to navigate. This is true of any language of course, but it can be more frustrating when you're operating at a higher level of abstraction. The Dotty project seeks to rewrite the Scala compiler in line with an improved framework of some of the more innovative type system features of Scala. I think it's ultimately going to lead to a better foundation with less gotchas. But it's still a long time coming.

Oh yeah, and the `implicit` system is a beautiful concept, but pretty unique to Scala, and intimidating at first.

[1] http://stackoverflow.com/a/26690131/807674

[2] http://stackoverflow.com/a/28036272/807674

Re: Scala School

#159
post #9

Earlier quoted context omitted.

I agree about painful learning curve for Scala. Problem I think in very divergent community and in different approaches for a every single problem (unlike for example Python or Go): OOP vs FP, Typesafe vs Typelevel, scalaz vs cats, Cake Pattern vs sanity. There's a also a problem that most powerful Scala techniques are there "by accident" [1] and unlikely will (or should) appear in official guides. Also I disagree th…

The community is the worst part IMO, and it all boils down to the Typesafe vs Typelevel communities. The typelevel crowd want to turn Scala into Haskell whereas the typesafe crowd have always recognized it as an ML dialect first and foremost. The rift pollutes and bloats your dependencies, and causes problems with unexpected behavior and unreadable documentation. Trying to shoehorn libraries into my projects that pol…

I find that the Typesafe (Lightbend) and Typelevel communities are more or less moving in the same direction. Using Shapeless, for example, doesn't seem to really conflict with more mundane Scala usage. I'd say that there's more of a contrast with the Scalaz world, where obscure category-theoretic terms and operators are unavaoidable.

That said, I've had plenty of success applying Scala at work without bringing in overt category theoretical concepts into my codebases. Scalaz remains very much an opt-in community.

Re: Scala School

#160
post #157

Earlier quoted context omitted.

Using the natural language style assertions is optional though, and only work if you incorporate the 'Matchers' trait in your tests. If that's too magical, you can still use plain old assertions or one of the other styles here http://www.scalatest.org/user_guide/using_assertions

Everything is optional, which is a nightmare for consistency. Using JUnit there's only one style of testing and every test follows it.

You can do what we did in my team: decide on a style of testing and stick to it (in our case, I liked WordSpec). With JUnit you can't do this, because there is only one style.

I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.

Post reply on HN