Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala School

twitter.github.io

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Scala School

#141

Post by jowiar »

kailuowang wrote: post #123
jowiar wrote: post #113

My biggest challenge with (learning) Scala and the Scala community is that it feels like nobody is actually shipping software, or advocating for making shipping software easier. And that's a shame, because Scala is language I love for writing a few dozen lines of code, and expressing a domain concept. It's a fantastic language for solving a homework problem set (and it's origins may be part of the reason why). But ev…

> nobody is actually shipping software What about Spark, Kafka and Akka? I actually think the Scala community is working very hard to improve user experience, it's just that they don't do in the expense of soundness. As a ruby -> Scala developer, I don't miss DHH.

Spark is interesting, and is probably the most pragmatic focus in Scala land.

On the Akka side: Try picking up Akka-HTTP and use it to write an API client (which seems like something one would do with an HTTP library). There are lifecycle issues that are undocumented, and it really feels like this wasn't a considered use case throughout the entire development process.

I don't necessarily think DHH is right on everything, or even most things. But I do think it's valuable having a voice saying: "Does this help us ship" or "We're adding this feature because it's solving a real problem we encountered multiple times during the development of real software, and it would be nice to have a standardized solution".

Re: Scala School

#142

Post by Negative1 »

Maybe I'm in the minority on this but I felt this guide by twitter was poorly written. It has good coverage but concepts were just not explained very well.

The way I learned was reading from front to back "The Scala Programming Language" by Martin himself and starting a new project completely in Scala (which I'm launching soon). I'm sure that's not the best approach for everyone but using Scala in a practical environment in an idiomatic way really helps ground the concepts which can at first seem intimidating and difficult to comprehend.

Mastery is a whole other story...

p.s. I recommend Scala Cheatsheet if you are just learning: http://docs.scala-lang.org/cheatsheets/

Re: Scala School

#143

Post by merb »

hythloday wrote: post #122
merb wrote: post #66

What I hate about Scala School is that they are still using Twitter Future's and not Scala Future's, that could be aweful for Beginners.

Twitter's Futures were developed when Scala's Futures weren't tail-recursive (and so not really production-quality). There's probably an item on the roadmap to port Finagle to using scala.concurrent.Future but I doubt it's high priority. The two support the same set of operations in any case - I doubt it'd be a huge problem for a beginner to translate one to the other.

Actually a Huge difference is that scala.util.Future takes a implicit ExecutionContext while com.twitter.Future does not.

Re: Scala School

#144

Post by argonaut »

mafribe wrote: post #101
argonaut wrote: post #77

Earlier quoted context omitted.

You are really stretching things by saying you'd be productive on day 1. Scala code has an immediate upfront complexity cost.

I have to agree with "lmm" and "the_af" here. You can use Scala as a "Java without semicolons", and indeed that's what I recommend to those who want to learn Scala coming form an OO background. There is absolutely no need to use fancy Scala features like higher-kinds or monadic effects. Indeed, there is no need even to use functional features. Scala is a perfectly fine OO language. The one thing I recommend to learn…

You are advocating that beginners start using Scala without really understanding what they're doing, and being mostly unable to read other code or read the source, while writing what is considered to be bad Scala from the get go. Contrast this to languages like Python or Ruby, where it is totally possible to immediately start writing code you understand that follows the general gist of good Python/Ruby style.

You are certainly right that someone new to Scala can get started quickly this way. You are wrong that Scala is anywhere close to the same level on this dimension as Python or Ruby or Go.

Re: Scala School

#145

Post by goldbrick »

justinhj wrote: post #133
mathattack wrote: post #127

Earlier quoted context omitted.

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?)

I was a long time hobby level Common Lisp and Clojure programmer when I started learning Scala. Understanding functional programming before coming to Scala definitely made it easier. That said I think Scala has a little extra learning curve because you need to understand some syntax especially around type declarations, and understand how flatmap and map work, not just on lists but on many different kinds of data stru…

It doesn't help that Scala takes a lax attitude towards functional principles whenever it's convenient -- for instance, you can map over a set, and certain maps will get you a different type back. Haskell it's not. It's more like a terse Java with optional types and pure functions added on.

Re: Scala School

#146

Post by goldbrick »

argonaut wrote: post #144
mafribe wrote: post #101

Earlier quoted context omitted.

I have to agree with "lmm" and "the_af" here. You can use Scala as a "Java without semicolons", and indeed that's what I recommend to those who want to learn Scala coming form an OO background. There is absolutely no need to use fancy Scala features like higher-kinds or monadic effects. Indeed, there is no need even to use functional features. Scala is a perfectly fine OO language. The one thing I recommend to learn…

You are advocating that beginners start using Scala without really understanding what they're doing, and being mostly unable to read other code or read the source, while writing what is considered to be bad Scala from the get go. Contrast this to languages like Python or Ruby, where it is totally possible to immediately start writing code you understand that follows the general gist of good Python/Ruby style. You are…

I don't at all agree that someone can pick Python or Ruby up and start writing idiomatic (or even "good") code on day one. In fact I make a good living consulting in JRuby shops where they thought they would get some sort of benefit by using Rails but then wrote all the code as if they were still using Java.

Re: Scala School

#147

Post by denisftw »

Scala for the impatient is a 400 page book that essentially teaches the syntax :) I can recommend a drastically less time-consuming algorithm:

1. Watch a 1-hour video that teaches HelloWorld-stuff in Scala: https://www.youtube.com/watch?v=DzFt0YkZo8M

2. Then read first 45 pages (free sample) of my book https://leanpub.com/modern-web-development-with-scala

Re: Scala School

#148

Post by hythloday »

merb wrote: post #143
hythloday wrote: post #122

Earlier quoted context omitted.

Twitter's Futures were developed when Scala's Futures weren't tail-recursive (and so not really production-quality). There's probably an item on the roadmap to port Finagle to using scala.concurrent.Future but I doubt it's high priority. The two support the same set of operations in any case - I doubt it'd be a huge problem for a beginner to translate one to the other.

Actually a Huge difference is that scala.util.Future takes a implicit ExecutionContext while com.twitter.Future does not.

It is for production. It's not for a beginner - they should just be using scala.concurrent.ExecutionContext.global.

Re: Scala School

#149

Post by lmm »

incepted wrote: post #119
lmm wrote: post #87

Earlier quoted context omitted.

The Java interop is worse than that of Scala - Kotlin can't represent Java's variance (i.e. existential types) so it has hacks to avoid it. It doesn't have the maturity or ecosystem of Scala. The "pragmatic" design feels like they took a grab-bag of features from Scala and implemented all the simpler use cases individually, with no appreciation for the underlying coherence; IMO the language will not be able to evolve…

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 methods that return existential types (e.g. List) everywhere. If you can't represent that type in your type system (note that it's not the same type as List), you can't have full Java interop.

Re: Scala School

#150

Post by lmm »

the_af wrote: post #129
lmm wrote: 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.

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.
Post reply on HN