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

81–90 of 178 posts

Re: Scala School

#81

Post by haggy »

20andup wrote: post #42
StreamBright wrote: post #15

Earlier quoted context omitted.

The real question: is it worth it? Up to now I could successfully avoid learning Scala. My problem with it is the complexity that the language by itself introduces and the readability of code that comes out at the end. Maybe I am just valuing simplicity too much when it comes to programming languages. Anyways thanks for the impatient guide!

Yes as a programmer. No as startup guy. For me, it's like learning to do multiplications instead of just adding and subtracting. You will still get the same answer at the end. For a startup, you don't want to your programmers to learn cause its a heavy investment in terms of time. Adding and subtracting works just fine so they often advocate that route. You definitely get to the end goal, but when it comes to learnin…

Im currently at a startup and we're trying to introduce more Scala into the pipeline. I agree that languages like NodeJS can speed up time to market slightly but we are taking a huge hit for it right now as we try to scale with 5x/10x load. I really wish we introduced more Scala/Java up front.

Re: Scala School

#82

Post by lmm »

argonaut wrote: post #77
lmm wrote: post #62

Earlier quoted context omitted.

You can be just as productive as you would be in Python/Ruby/JavaScript/Go from day 1 in Scala - usually the same code will work, with minor syntax differences and maybe the occasional type annotation. The difference is there's more to learn in Scala that will make you even more productive, but that should never be a downside, and you don't have to learn it if you don't want to.

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

I am speaking from direct personal experience. Explicit effect sequencing is optional (in contrast to Haskell), traditional OO with inheritance is available. You may not be able to read all the standard library type signatures on day 1 but the documentation is adequate without them. Anything you could do in Python/Ruby/Javascript translates directly; in the very short term I guess not having a single baked-into-the-language concurrency model like Go is a disadvantage, but the use case where you'd need that on day 1 is pretty rare.

Re: Scala School

#83

Post by airless_bar »

sulam wrote: post #11
badminton1 wrote: post #2

I have heard that Twitter is now moving away from Scala.

It was considered at one point, but the main proponent for one JVM language has left the company and even before that there was strong support for keeping Scala on the list of production languages.

> the main proponent for one JVM language

Hey, I'm interested in that! What proponent? What language? If it was Raffi Krikorian would you mind having a look at https://en.wikipedia.org/wiki/Scala_%28programming_language%... and perhaps update it?

Re: Scala School

#84

Post by the_af »

argonaut wrote: post #77
lmm wrote: post #62

Earlier quoted context omitted.

You can be just as productive as you would be in Python/Ruby/JavaScript/Go from day 1 in Scala - usually the same code will work, with minor syntax differences and maybe the occasional type annotation. The difference is there's more to learn in Scala that will make you even more productive, but that should never be a downside, and you don't have to learn it if you don't want to.

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

With a few exceptions, you can program in Scala as if it were Java++. You won't take full advantage of Scala, but it can be done, and beginners sometimes do precisely that.

Re: Scala School

#85

Post by morsch »

Zaheer wrote: post #8

My biggest problem with Scala is that it's too powerful. Reading code I've written weeks or even days later is painful. Conciseness is not always good.

I find that I consciously need to go over any code and rewrite it with a reader in mind. The first version is usually crap, but at the same time, it's very easy to fall into the trap of making it Just Right which makes the second version "super elegant" but completely opaque at the same time.

I often end up making a "super elegant" version and, almost invariably, end up scrapping it for a (hopefully...) more bread-and-butter version, which may or may not incorporate some lessons learned from the concise version. Even if not, it's not all loss, because coming up with the elegant version is intellectually rewarding and super fun.

Add lots of in-line (not just scaladoc) comments helping the reader along. Extract vals for intermediary steps. Variable naming is always important, but even more so when you don't explicitly declare the type.

Re: Scala School

#86

Post by the_af »

Chris2048 wrote: post #74
lmm wrote: post #64

Earlier quoted context omitted.

It's the best language going these days, IMO; it's a real sweet spot in terms of power, flexibility, maturity, ecosystem and learning curve. It's not the best at any one thing but it's the best overall language. Haskell is possibly more powerful, but it's (for many people) harder to learn and doesn't have quite the same library/tool support. Ceylon (or Idris) is probably better designed, but you won't find much in th…

How does it compare to Python or Ruby?

I assume you know this, but it warrants saying explicitly: Scala is statically typed, while Python and Ruby aren't. This has immediate practical implications which for many people (on both sides of the divide) are A Big Deal.

In terms of elegance and succinctness, Scala is somewhere in the middle between Java's bureaucratic verbosity and Python's terseness.

Re: Scala School

#87

Post by lmm »

arkadiytehgraet wrote: post #69
plinkplonk wrote: post #47

Earlier quoted context omitted.

If you have to use the JVM and don't want to code in Java, your options are Scala or Clojure (maybe Groovy?). Then it comes down to essentially the tradeoff between a static typesystem vs macros (imho, ymmv etc). I second the reccomendation for Chuisano and Bjarnasaon's "Functional Programming in Scala".

What about Kotlin? Its 1.0.0 has been recently released and comes as "pragmatic" Java, bringing a lot of useful features and having more concise yet readable syntax. Also, the Java interop is really good (better than that of Scala, for instance).

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 because it has too many special cases. And Ceylon does everything it does but better. Kotlin is a triumph of marketing hype, nothing more.

Re: Scala School

#88

Post by lmm »

rtpg wrote: post #56
joshlemer wrote: post #10

Earlier quoted context omitted.

In what ways does Scala you've written end up being unreadable just days later? I honestly find that Scala code is some of the simplest and easiest to reason about of any language. Writing Scala has honestly been such a joy, it's easy to refactor, easy to read and write, and I almost never miss something -- if it compiles, Scala code is usually correct I find.

I think that, if you're not super aware of most of the features of Scala, that it can be confusing to understand what certain syntax means (implicits are a big one!) Just the infix operator syntax plus implicits can lead to stack trace confusion all around And try understanding some of the type signature funkiness! It can be difficult I definitely think that Scala is a harder language than most to grasp, if only for…

Scala's infix operator syntax is very mechanical. Much easier than e.g. Python where you have to remember whether a * b desugars to a.__times__(b) or a.__star__(b) or something else. The IDE support for those and for implicits is very good these days.

The type signatures can be complex but only when you're doing complex things with them - if you stick to doing the kind of things you'd do in another language you'll get similarly simple types.

You're absolutely right that the native stack traces are poor, but you can use tools that understand them better, e.g. Takipi.

Re: Scala School

#89

Post by Chris2048 »

the_af wrote: post #86
Chris2048 wrote: post #74

Earlier quoted context omitted.

How does it compare to Python or Ruby?

I assume you know this, but it warrants saying explicitly: Scala is statically typed, while Python and Ruby aren't. This has immediate practical implications which for many people (on both sides of the divide) are A Big Deal. In terms of elegance and succinctness, Scala is somewhere in the middle between Java's bureaucratic verbosity and Python's terseness.

Yes, I used to mainly work with Java, but now mainly Python. I was wondering if "best language going" had considered these two languages.

Re: Scala School

#90

Post by ssmoot »

the_af wrote: post #86
Chris2048 wrote: post #74

Earlier quoted context omitted.

How does it compare to Python or Ruby?

I assume you know this, but it warrants saying explicitly: Scala is statically typed, while Python and Ruby aren't. This has immediate practical implications which for many people (on both sides of the divide) are A Big Deal. In terms of elegance and succinctness, Scala is somewhere in the middle between Java's bureaucratic verbosity and Python's terseness.

Scala code will generally have a slightly lower LoC than Ruby IMO. Maybe 20% overall typically. And the lines will be longer.

Ruby forces new lines for many expressions that Scala doesn't. (Think class with accessors vs a typical case class.) as things get more advanced, Scala allows you to express things that can be very difficult or awkward in Ruby. Like function composition, currying, pattern matching.

There's not really a case where a Ruby program will typically be shorter than a Scala program (well, excluding imports since there's no shared global namespace in Scala), even if you're avoiding typelevel style programming.

Post reply on HN