This is a good thing. The Akka versions of Futures and Actors seems a lot more solid to me than the existing Scala ones, and also seem to perform better.
uh, what do you guys do exactly ? Folks on TC are asking the same question btw. Are you building a fastclick 2.0 ? fastclick++ ? fasterclick ? fastclickclick ?? Heh. Seriously would like to know what it is you use scala for. "next-generation online media technology" is just too vague.
I don't much about Scala, but looking at the examples on http://www.simplyscala.com/, it looks like the language has a lot of syntactic sugar. Scala users, is that an accurate assessment or I am misjudging it?
I disagree. The following all mean the same thing (off the top of my head):
obj.( (a, b) => a + "." + b)
obj.(_ + "." + _)
obj { (a,b) => a + "." + b }
Seems to me that's syntactic sugar. The flexibility of Scala is the source of my love/hate relationship with the language. That being said, it's still my favorite thing to code in when I get the opportunity...
Optional dots, semicolons and sometimes parenthesis, underscores as placeholders, and interchangeable parenthesis and braces are about the only syntactic sugar in Scala AFAIK. They are really minimal compared to, for example, Python decorator syntax.
Scala has to be the worst offender of language complexity I have ever seen. A language isn't supposed to make you feel smart, it's supposed to be easy to read, maintain and write powerful code in. Have you had a look at larger Scala codebases? Every single code line needs to be read consciously, quickly scanning over code is impossible with Scala.
You can code a domain specific options parser in scala so that your final code actually looks like this -
"@ $20 spot, price 5 calls, @ $25 strike, 59 days to expiry"
This is as simple as it can get. In fact, the senior quants literally say the above line word for word. So its practically English. Can't get any simpler than that.
How much Scala have you read and written? I hear "xxx is too complicated" quite often, and it's always from people whose experience is having visited the language website once or twice.
Of course code is hard to read if you don't know the language.
Definitely Programming in Scala - http://www.artima.com/shop/programming_in_scala. You might find some parts of the book a little boring if you already have experience with functional programming, but it is one of the best books about programming languages I've read (I've only read the second edition, not the one that is available online, but I guess, the first one will be OK as an introduction too).
don't buy the wampler book as a 1st book. too many forward references, you are constantly flipping pages.
also, portions of the scala api are a work in progress. constructs for multidimensional arrays have changed several times.
i may recommend the wampler book when they come out with a rewrite, say in a few months time. Now it seems too rushed. Some of it reads like a collection of blogposts.
Also wampler's idea of functional programming is very basic. No details on commonly used functional data structures or functional pgmming algorithms. More like "functional pgmming is X as opposed to OO pgmming is Y".
Okasaki's book ( http://news.ycombinator.com/item?id=1138979 ) needs to be written in Scala. That'll sell a boatload of copies. Even a modest attempt at that would work for a start. That's an awesome book.
I love Scala. So much so that I've wrung my brain trying to find places where it'd really make sense in my toolkit. I keep coming up empty though. I work primarily in Rails on the front end and if I need some "boom-boom" on the backend, generally that's going to involve services written in node.js, Java (rarely), or C. There are excellent Java libraries that I can exploit for heavy lifting by using JRuby. I've never had issues "scaling" business logic from either a human or a technical perspective in Ruby.
Is there a "killer app" for the Scala/Akka stack that I'm missing?
Is there a "killer app" for the Scala/Akka stack that I'm missing?
Many people don't like to maintain polyglots. Scala is expressive enough to write your frontend code in, but fast enough to also handle your backend code.
Say what? Scala is statically typed, and does some awesome type inference so that you don't have to declare your type every place you declare a variable. It may look dynamically typed, but its not (http://programming-scala.labs.oreilly.com/ch12.html).
There are numerous holes in the type system. Just browse their bug tracker to see. And several of them are not just "bugs" but deep flaws in the type system.
I think the key thing is that there is no mechanism to be sure that messages you send to actors are immutable. There is a compiler plugin in development to help, though.
So I'm curious, can you point to known problems with Haskell or ML that do not involve using the unsafe features? Scala has problems even without resorting to "unsafe" features like casting or native methods.
GHC 7 recently broken with the traditional ML type checking / inference mechanism because it's not expressive enough for the kind of the code that Haskell wants to support. Noone has this stuff figured out, certainly not ML, Haskell, or Scala. Benjamin C Pierce has even written about how some domains are positively painful w/ strong type systems and how contracts are a more expressive solution.
I'd like to see the ideas behind the Art of the Metaobject Protocol applied to type systems. Allow users to selectively fill those holes that relevant for their domain.
I don't see any mention of a specific safety problems. Plus, I am given to believe that there are actually numerous papers on the extensions involved in the Haskell type system. Consider http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
That is the paper I'm referring to. Type safety is an arms race with expressiveness and the paper pretty much says so.
REPLY: You're argument is reductive to the point of being useless - i.e. you could write a type checker for a domain of programs so small as to be comical. type safety and the domain of the provable programs are inextricably intertwined.
I guess I'm not following, because type safety is a property of typed language. Expressive power is orthogonal. There are type systems that are more expressive and less expressive and ideally you design your language so that regardless of where it lies on the spectrum it has type safety. Otherwise, the type system does not really provide you with any real guarantees.
"I guess I'm not following, because type safety is a property of typed language. Expressive power is orthogonal."
This is where you have it wrong, and it's well known that it's wrong. Anyways...
Scala's is a series of compromises made to give a more expressive type system to a language that interacts with the JVM and and Java libraries. Saying its not "safe" to some arbitrary metric is neither insightful nor helpful to anyone. You can find it as "ironic" as you like, but it's not a particularly fair criticism by many metric.
I'm guessing you've never actually proven type safety for a non-trivial language, if any. While there are many ways type safety could be stated for Scala, I'm pretty sure most Scala programmers would like the version of type safety that states "if I never use a type cast, I can never get a class cast exception." If you think that is too strong of a statement, then fine, but I think most people would agree this is a reasonable expectation for Scala.
a type system can be both logically consistent and expressive. the trade-off is with things like the efficiency with which it can prove the program is correct (and even the possibility that it cannot be proved at all).
what typesafety is talking about is errors. not trade-offs. that the type system says something is safe when it is not.
Hm... As an early Scala/Akka developer, and contributor I would like to see these issues addressed by the team because I'm seeing a lot of trac jacking going on. This usually only happens when there isn't a response to issues.
I didn't find these bugs, they're just ones that have been accumulating over the years. If all of these were as simple as being "bugs" rather than flaws in the type system why wouldn't they have been fixed by now?
Is there something wrong with trying to encourage them to fix these problems and make Scala all the better for it?
That does seem to be the business model they are applying here. Will be interesting to see how long they go before they are acquired, just as SpringSource was by VMWare.
Red Hat & VMWare would seem to be the most obvious bidders for Typesafe as they both offer Java-based stacks with enterprise support that Scala & Akka would fit in very well with.
I imagine it will take several years, but thats probably the path. CTOs look for this kind of (enterprise) support ecosystem before investing in new technologies. Given Scala's documented easy transition for Java developers, and the fact that Java is getting really old, I'd wager this is the next big (non-MS) enterprise language. The training/support/tools company is the inflection point.
This is great news. I like Scala and I like how you can mix it with old Java code. Doing so you have an easy migration path and you can gain productivity at the same time.
Absolutely awesome. I've been rewriting most of my financial analytics code in Scala & its a genuine pleasure to see code sizes reduce 5-6 times & being a lot more expressive at the same time, not to mention speed improvements.
Just yesterday I had an interview for a developer position with a hedge fund where the partners used M$ Excel, M$ SQL Server, M$ VBA macros and a bunch of Bloomberg terminals for the datafeed. I had prepared a presentation that advocated Scala as the primary toolset, Hadoop on the backend & a couple of DCOM hooks ( JIntegra ) that got data in & out of the Bloomberg & the rest of M$ world without getting all tangled up in M$ land.
Must say I didn't get very far. "Seems too cutting edge, no commercial support, we only have few 1000 rows so why not just use a SQL Server, what about front-end solutions for this newfangled language, does Scala do reporting, does Scala talk to Bloomberg, do other IB's use Scala, we'll use Scala when an IB starts using Scala " were some of the concerns I got.
They haven't said no, but I have a feeling they'll end up hiring a dotNet veteran who'll happily code VBA macros till the end of time instead of taking a chance on a platform that'll genuinely change the nature of s/w development as we know it.
Its amazing to see people happily betting the farm on CDS defaults of XYZ company, where they stand to lose a couple hundred million dollars if the bet goes wrong. But the same folks won't bet on a promising new technology because its too new & has no commercial support, preferring instead to stick with 30 year old M$ tech due to comfort level. The chance of a loss here is several orders of magnitude lesser, yet they don't get it.
I've been rewriting most of my financial analytics code in Scala & its a genuine pleasure to see code sizes reduce 5-6 times...
What did you write your analytics code in before?! Most quants use R, Matlab, q/kdb+, OCaml, Python, etc. I can't imagine an analyst would ever use a language like Java or C++ for research.
M$ Excel, M$ SQL Server, M$ VBA macros
Also known as: what most of Wall Street uses. Are you sure you want a career in this industry?
what about front-end solutions for this newfangled language, does Scala do reporting, does Scala talk to Bloomberg, do other IB's use Scala
All of which are legitimate concerns. Did you bother to address any of those?
As the others have mentioned, banks aren't looking for "fast" or even "productive"; they're looking for "reliable". Wall Street doesn't chase technology the same way Silicon Valley does. Remember the FourSquare outage (MongoDB) or the numerous issues with Twitter back in the day (Ruby on Rails)? Banks need to have better uptime than that.
We used to talk longingly about using strongly typed languages when I was at an IB. We mostly used perl for munging data and SAS for actual heavy lifting. It would have been great to have the compiler yell at me for adding a return to a dollar value or whatever.
Were you at ETL? The prop group I was in at Morgan used q/kdb+, which was great for a lot of things but did cause some trip-ups that static typing would have prevented. My group eventually shut down and I left the firm, but I had heard Morgan was looking into F# to use company-wide. (I used Ada in a previous life, so I know full-well the benefits of strong typing.)
Dude, chill. I have worked on Wall St for over a decade at this point . There is a huge, HUGE diversity. Some use toolsets they are comfortable with, others with what they get interested in ( after it crosses a certain stability threshold ofcourse ). BTW R itself gained mainstream acceptance in 2009+. I can imagine you saying in 2008 no quant in their right minds would use R, its just too new. It was new then, but it's defacto now. That was true of OCaml which Jane St uses almost everywhere now but didn't do so just a few years back. Ofcourse there are quants using C++ for all their risk analytics - 50% of my classmates got hired on that very credential! As to Java, I have personally written trading software for IBs in Java way back in 2002 that used pricing modules for all the instruments also written in Java. Guess how mainstream Java was back then ?
Finally, there are actually fairly decent risk analytics DSLs in Scala out there.
Other than reporting ( you really can't compete with SAP/Crystal Reports on that front), solutions in Scala address the rest of your legitimate concerns using DCOM hooks to pre-existing C libraries & DLLs. Why reinvent the wheel ?
I don't see why you are getting so worked up about my "inexperienced rant". I simply described a real-life situation I encountered which I felt was funny viz. highly risk-taking alpha personalities getting hugely risk-averse when it comes to something quite innocent like language adoption.
The reason I criticized your post (and I'm not the only one)
is that I don't want a young'un to read this and believe that's the right way to be thinking about career or business decisions.
You interviewed somewhere that isn't for you. So try someplace else. Whining on the Internet about "teh M$" doesn't make you look like a brazen intellectual.
Argh! If I'm in the midwest now can't I have worked in NYC before I moved here (which is what happened btw, now that you are so curious about my antecedents). And M has taken so many $ from me in the form of numerous OS updates & backups that I can justifiably call them M$ :) Should one be an intellectual to play around with scala ? Jeez.
Alright, truce. I thought I had remembered a Scala career question on Quant Stack Exchange (I'm a moderator there). So there are a couple finance shops that use it:
They are getting paid to take the risk on financial instruments, because they're experts at it. They have no need to take any risks on their technology infrastructure.
They "think" they are experts at it. Yeah. If they were experts at predicting which ones would fail, they would simply buy shitloads of puts on xyz & wait it out instead of hedging themselves in case xyz doesn't default.
Also, you give them too much credit when you use words like "technology infrastructure". I've been to many of them & the extent of their infrastructure is RAID & the extent of their technology is writing a for loop in VBA.
I somewhat agree with you, but you have to admit when you see 'M$' you instantly gleam an assumption of what the person thinks. In that respect its high context, and like I said you have to admit that. Especially so if it illicits a strong emotional reaction to rebut it's use in you no?
Say you decide to code up a bunch of risk analytics in Scala. Say Scala doesn't do it for you 2 years from now. You really haven't lost anything - just hire a bunch of VBA jockeys & they'll migrate you back to Excelland in a reasonable span. This isn't complicated device driver code where module A invokes module B with assembly address C...More like convexity on the 10 year swap is different from 2 5 year swaps & that difference can be exploited with a bigsize bet on payoff X and a ratio hedge in case bad things happen. Whether you do all of the linalg/stat/regression scenario analysis in Excel or call a Mathematica routine from Scala should be irrelevant, you get the same answers. So I simply think the risk-reward ratio is out of whack. You're willing to take huge risks on stochastic variables 10 years out into ther future but unwilling to touch a programming language/platform because its too new, even when there's a clear-cut migration path. Seems silly. Don't see how that attitude translates to being cynical about finance.
"Over the next versions, we plan to gradually merge Akka with scala.actors"
Martin Odersky - http://groups.google.com/group/scala-user/browse_thread/thre...