71–77 of 77 posts
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: jorge@foursquare.com
Coursera has a class as well. Martin Odersky tweeted a while ago about a possible advanced course in the fall but it doesn't look like it's happening yet. http://www.coursera.org/course/progfun
Earlier quoted context omitted.
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…
For simple programs that do not need to be debugged, laziness is great, you can write some very concise code. Once you are debugging however, you want to expose as much control flow as possible to break and step through. I say this from writing 10s of thousands of Scala code in a fairly complicated context (Scala compiler + Eclipse) with non-trivial control flow (mostly event driven).
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…
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?
Be careful; once you've been working in Scala, going back to Java is unpleasant. =)
Earlier quoted context omitted.
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.
Scala only has very limited inference. In fact, so limited that, based on this criterion alone, I would take Java's powerful refactoring tools over Scala's inference anytime. (One of my main uses of inference is enabling fearless aggressive refactoring.)
But let's say Scala had a type system amenable to global inference with a nice principal types property. This does not prevent you from having to annotate types when, at a module boundary, you want a term to have a more specialized type than its principal type. (Within module boundaries, it is admittedly no big deal to have terms whose types are more generic than their use would warrant.)
> "no semicolons, and a shorter form of final"
You cannot tell me with a straight face that cosmetic syntactic changes are a particularly compelling reason to switch languages. (Well, you can, but then you cannot convince me you are a pragmatic engineer.)
> "it's already an improvement over java."
Yes, but, without taking advantage of Scala's powerful type system, is the improvement over Java substantial enough to justify the investment in learning a new language?
Earlier quoted context omitted.
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.
> "java with type inference" Scala only has very limited inference. In fact, so limited that, based on this criterion alone, I would take Java's powerful refactoring tools over Scala's inference anytime. (One of my main uses of inference is enabling fearless aggressive refactoring.) But let's say Scala had a type system amenable to global inference with a nice principal types property. This does not prevent you from…
What investment? You just write the same code that you were writing in Java. You can do that on day 1 (at least, assuming your IDE and build system have scala support already) - on day 1 your productivity is just as high (or slightly higher, because of the cosmetic syntax improvements) as it was in Java. On day 2 your productivity is higher, as you pick up a little bit of scala. So there's no initial cost - just an improvement. I know this is possible because I have done it.