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

61–70 of 77 posts

Re: Scala School

#61

Post by seanmcdirmid »

pkinsky wrote: post #60
seanmcdirmid wrote: post #52

Earlier quoted context omitted.

I worked with Scala at EPFL during my 2 year post doc (in Martin's group). I later started working for Microsoft, and found the transition to C# to be initially painful but not incredibly so. I'm now a happy C# programmer, though I take a lot of liberties [1] with the system, and I also use C# mostly to build programming systems of my own [2] (though Scala has had an everlasting influence on my own work). C# is a bit…

In my (limited) experience, for expressions make for some of the most concise code I've seen. So many problems can be represented as a chain of Options or Futures mixed with standard {val x = expression y} expressions.

But why would you want to? Even in Scala? Use Futures only when bothered with async IO, and even then be very careful about it. Options always made debugging more difficult because they defer where you get your NPE.

Re: Scala School

#62

Post by wpietri »

catnaroek wrote: post #57
dustingetz wrote: post #46

Earlier quoted context omitted.

I'm leading a scala transition at a javashop. I think you need a crital mass of people who understand scala as well as a lot of respect for your colleagues for this to go smoothly, 10x so if you have legacy code. There will be some very tense discussions about how things ought to be implemented, and if not well managed, it can feel like "this approach is wrong, your code is bad and you are a bad engineer" which is to…

It should be evident to anyone with a modicum of understanding of what types are for, that Scala is a superior language to Java. (And Haskell even much more so, but Scala is friendlier to your existing investment in a Java codebase.) > There will be some very tense discussions about how things things ought to be implemented (...) Encoding as much as possible of the problem domain's logical constraints in types. Any p…

You omitted the part where the previous poster described that quote as toxic.

If you see your time as much more precious than your colleagues, and default to treating them with contempt, you're going to have a hard time finding colleagues. Which you may not care about.

But what should matter to you is that it's basically a self-fulfilling prophecy. If you treat your colleagues like that, they're never going to get better, and they're going to be the ones who eventually vote to throw out all your beautiful code and go back to Java, where they at least understand what's going on and nobody condescends to them all day.

Re: Scala School

#63

Post by sbilstein »

pkinsky wrote: post #29

I've finished Martin Odersky's Scala Course. I've built a few small play2.0 apps. I've used Scala to solve ~20 Project Euler problems, and I'm fiddling around with parsers and scalaz. However, all the Scala positions I've found are looking for engineers with experience using Scala in production. How can I make that jump? Are there any opportunities out there for junior engineers who are proficient in Scala?

Linkedin uses Scala for many different teams. My team does. Apply and tell the recruiter you want to work for a team working with Play with Scala.

Re: Scala School

#64

Post by pkinsky »

seanmcdirmid wrote: post #61
pkinsky wrote: post #60

Earlier quoted context omitted.

In my (limited) experience, for expressions make for some of the most concise code I've seen. So many problems can be represented as a chain of Options or Futures mixed with standard {val x = expression y} expressions.

But why would you want to? Even in Scala? Use Futures only when bothered with async IO, and even then be very careful about it. Options always made debugging more difficult because they defer where you get your NPE.

Isn't the point of options to statically rule out the possibility of NPE's?

    def f1:Option[Int] = Some(1)
    def f2(a: Int):Option[Int] = Some(a + 1)

    val r = for {
        a
Individual error messages with scalaz's Validations

    def f1:Option[Int] = Some(1)
    def f2(a: Int):Option[Int] = Some(a + 1)

    val r: Validation[String, Int] = for {
        a  s"error: $e", r => s"result: $r")

Re: Scala School

#65

Post by seanmcdirmid »

pkinsky wrote: post #64
seanmcdirmid wrote: post #61

Earlier quoted context omitted.

But why would you want to? Even in Scala? Use Futures only when bothered with async IO, and even then be very careful about it. Options always made debugging more difficult because they defer where you get your NPE.

Isn't the point of options to statically rule out the possibility of NPE's? def f1:Option[Int] = Some(1) def f2(a: Int):Option[Int] = Some(a + 1) val r = for { a Individual error messages with scalaz's Validations def f1:Option[Int] = Some(1) def f2(a: Int):Option[Int] = Some(a + 1) val r: Validation[String, Int] = for { a s"error: $e", r => s"result: $r")

The problem is that on the JVM, you are given a debugger based on control flow, not data flow. Once you go into heavy option code, debugging that code becomes a PITA because your tools are simply wrong. So ya, you can come up with what basically amounts to a printf for data flow code, but you are stuck doing everything on your own at that point.

The problem really stands that no one knows how to build decent data-flow debuggers. Haskell programmers prefer static safety over debugging just as much as because their debuggers suck as the type system is so powerful. In Scala, you have the option to write crash-early strict code: do it, you will make your life so much easier as a result.

Re: Scala School

#66

Post by wiradikusuma »

stickhandle wrote: post #54

Timely. I'm interested in scala. Would love a couple opinions from those in the know ... (1) As a (very) experienced java guy, what's really the best learning approach: comparative? clean slate? I'd "like" to do Odersky's course, but I can't commit to scheduled tasks; (2) A minimal framework seems like a good idea to me - rather than Play!, what do folks think about Scalatra as a starting point?

if you want smoother transition, try my approach: code with Java style (OOP, imperative) but using Scala syntax. once you're familar with the new syntax, naturally you will wonder, "this seems clunky, there's got to be a way to do this the Scala way". and you'll start googling "how to do X in a list" etc.

to lower the bar, don't use framework. i even coded http://ngajakjalan.com (one of my projects written in Scala) without framework, just plain servlet+JSP. again, eventually you'll think, "i keep doing the same thing, there's got to be some library out there already doing this for me", and start exploring.

Re: Scala School

#67

Post by pkinsky »

ropiku wrote: post #47
pkinsky wrote: post #29

I've finished Martin Odersky's Scala Course. I've built a few small play2.0 apps. I've used Scala to solve ~20 Project Euler problems, and I'm fiddling around with parsers and scalaz. However, all the Scala positions I've found are looking for engineers with experience using Scala in production. How can I make that jump? Are there any opportunities out there for junior engineers who are proficient in Scala?

I went the other way, started working at Twitter without knowing Scala and it wasn't hard. We also have great internal Scala classes. Feel free to email me for more info (see profile). We're just looking for smart people, you don't need to have experience with Scala.

sent, thanks!

Re: Scala School

#68

Post by lmm »

catnaroek wrote: post #26
trailfox wrote: post #18

Earlier quoted context omitted.

...and the only way you learn how to write more elegant code is to start writing code...

In my experience, jumping straight to writing code results, if anything, in a huge mess. For anything more complex than proof of concept programs for specific language or library features, this quickly becomes unmanageable. I have obtained much better results by first developing a nice logical model (not necessarily 100% formal, but at least rigorous enough to be amenable to formalization), and only then picking a pr…

The new syntax is similar but nicer. If you just use Scala as "java with type inference, no semicolons, and a shorter form of final" it's already an improvement over java.

Re: Scala School

#69

Post by pkinsky »

seanmcdirmid wrote: post #65
pkinsky wrote: post #64

Earlier quoted context omitted.

Isn't the point of options to statically rule out the possibility of NPE's? def f1:Option[Int] = Some(1) def f2(a: Int):Option[Int] = Some(a + 1) val r = for { a Individual error messages with scalaz's Validations def f1:Option[Int] = Some(1) def f2(a: Int):Option[Int] = Some(a + 1) val r: Validation[String, Int] = for { a s"error: $e", r => s"result: $r")

The problem is that on the JVM, you are given a debugger based on control flow, not data flow. Once you go into heavy option code, debugging that code becomes a PITA because your tools are simply wrong. So ya, you can come up with what basically amounts to a printf for data flow code, but you are stuck doing everything on your own at that point. The problem really stands that no one knows how to build decent data-flo…

Is it realistic to split long chains of Option into subfunctions returning Option? If long chains of Options are hard to effectively reason about, breaking them up could ameliorate the problem.

I suppose that conceptually, I consider returning None inside a chain of flatmapped options as the equivalent of terminating early. It's not hard to pass along an object describing the error instead of None, which gets you the equivalent of a thrown exception.

Also: can you point me towards any examples of this antipattern? I 'd like to see it in action, if only so I can avoid it in my own code.

Re: Scala School

#70

Post by pkinsky »

dberg wrote: post #56
pkinsky wrote: post #29

I've finished Martin Odersky's Scala Course. I've built a few small play2.0 apps. I've used Scala to solve ~20 Project Euler problems, and I'm fiddling around with parsers and scalaz. However, all the Scala positions I've found are looking for engineers with experience using Scala in production. How can I make that jump? Are there any opportunities out there for junior engineers who are proficient in Scala?

send me your resume developer@huffingtonpost.com

Thanks, sent!
Post reply on HN