Alexy Khrabrov interviews Max Cantor on Haskell and Scala Startups

Alexy Khrabrov interviews Max Cantor on Haskell and Scala Startups

Recording: Alexy Khrabrov interviews Max Cantor on Haskell and Scala Startups

max has an amazing experience in using functional programming languages in a variety of settings in finance in in startup world uh and uh we're gonna talk about basically all kind of languages he used and all kinds of scenarios so max maybe we can start by telling us a little bit you know like your few previous years experience and like what kind of cool languages and technologies you got to play with so my first exposure to functional programming was it didn't hold it was you know taking the computer science classes in university where you learn how to play with linked lists and maps and you never touch it again so that didn't hold the second exposure was at a really amazing company called james three capital i was a trader out of tokyo but because even though as a trader i had some technical experience so i got heavily involved in the systems and quant systems and development back testing and that was all uh ocamo so you know of the three other people in the office no one knowings was completely self-taught and started reading up and realized that you can actually do productive stuff in these functional programming languages um you know i was kind of shocked all i thought about camel was you know implementing a dfa and nfa and you know all the theoretical fun stuff in university but you know jn street made was making millions and millions of dollars off a technology stack that's nothing but o'camel and excel spreadsheets with vba so obviously camel's really doing the heavy lifting there uh so i had a great experience at jane street and then i had a kind of meandering career through finance where i finally left uh to launch my own startup in singapore it was a loyalty card startup it wasn't an exciting business but the technology we built was very proud of what we did is we wanted to have like those punch cards you know buy one by ten sandwiches get one free but rather than qr codes or some kind of weird technology our app would actually scan a receipt and send the receipt image to the server we would parse it pull it apart perform structure analysis on the receipt image and you know figure out what the customer bought how much they spent and you know assigning their points accordingly where we could also tell the merchant what people were buying we gave them much richer debt the business failed we did a pisport job of marketing it uh we basically solved an existing problem but we did we built some really cool technology so the technology we used we had a full haskell stack the web app side of the application was fully powered by a web framework in high school called yasod which is you could describe it as a radically type safe web application framework you know your html templates your all interactions database it's type checked in a sense that you never really get with conventional frameworks or even you know conventional statically typed languages like java c-sharp et cetera and then the mobile app was 99 html5 and javascript generated by this yasod web app wrapped in a small phonegap layer so we could deliver updates to the client over the year either you need to go to the app store uh the receipt scanning required some custom c code that we wrote which we packaged up as a phone get plugin or java code on android and then we have this full stack and we're really proud of it and even though we didn't do a great job on the business the technology was pretty cool that's that sounds really great i think there's a lot of interesting uh entry points here uh so let me let me uh start with uh camel uh i mean uh i think eurominsky has uh several talks available on the web and a lot of uh folks in fb uh have seen them where he talks about the sweet spot which we show camel so that it's functional enough uh but it's not you know huskyly enough uh to be sort of uh productive but but not overly uh esoteric uh and i mean it's it's really surprising right and interesting how how it can power uh uh j-street so they are as understand have their concentrators and the camel as we know is not fully fully concurrent right so i wonder and a lot of people hold against it and and so on the first of all how that plays out and how you know how it's it enables the company to trade in a very fast fashion without being blocked by concurrency effectively which is like the language does not support you know like full threaded mold yeah so one of the i'm not sure if i should say this one of the dirty secrets of oh camel and james from camel is that the way they really squeeze out productivity is essentially by programming imperatively within a camel um i i don't think it should be a dirty secret i think you know that is the strength of a camel that lets you get that imperative programming um you know for instance a really simple example of using uh maps versus hash tables so no camel maps are functionally clear functionally pure referentially transparent immutable uh data types that when you alter a map you actually just get a new one correct and hash tables are not they are destructive non-thread safe they're actually in-place memory updating so they're not pure and beautiful and everybody uses them because they're orders of magnitude faster yes so for me i think the sweet spot in ocamo basically comes from the fact that it lets you cheat in a sense uh similar to scala whereas haskell does not in the long run i actually think haskell is a better solution jan street actually has one saying that which is that programmer time is more expensive than cpu time and this is for a high frequency trading shot you know where like clock cycles have actually you know calculable costs in terms of how you know how many cycles something takes to calculate will actually cost you trades and even though they felt that the cpu time was you know not as expensive as developer time and i think the assurance that haskell gives you in the long run does save the developer time um having said that you know ocam is a great language and relative to what 99 of businesses use which is you know sharper java a camel is uh so much better that's not almost not worth talking about relative to sharper java so you know james street's done a great job of that i you know on the one hand i kind of disagree with uh ron um and i think a lot of jane street's oh camel uses kind of a historical accident that's kind of what they happen to be using in a group i think when they started haskell was even though haskell was an older language high school was more immature at the point that they started using it uh now haskell's really caught up i think haskell's much better solution however ron is you know absolutely brilliant he's done amazing things at jane street so you know so but uh in terms of concurrency i'm still curious because that's kind of a lot of uh people and i know you can implement several processes and which is essentially what they use yeah and i mean that's the only choice left to you but would you say that mentally uh folks would like to use uh other models uh i mean like would you see internal debate or desire to use this for financial applications uh or or is it just not what how people think i mean maybe it's just easier to think in terms of lose a couple processes which communicate sometimes through shared memory somehow and maybe that's the way to to write this kind of application so it depends on your problem scope um one thing about the problem scope that generate deals with is and i should say i'm a couple years out of jane street so information is a little data but for the most part the problems they deal with are highly partitionable um the computations involved in pricing one particular security with the audience of these are not super difficult what's difficult is doing it for the universe of securities in real time however it's pretty easy to just separate your universe and partition them and you know run multiple processes that isn't necessarily the case in a lot of other applications you know especially if you get into any kind of like social networking or graphical stuff it's much harder to partition that so that's where something like a haskell or you know hopefully one day rust will be stronger relative to ocala you know if your uh space is partitionable you know you can kind of get away with a camel but then you're not really getting that much relative to conventional imperative programming languages yes yes i see so another interesting thing is i remember that uh during the financial crisis of 2008 i think uh janes3 did well and the reason you know they like i heard one of the reasons is i mean it's it's a it's a hyper concentrator and they're basically you know training very fast so would you say that okamel was one of the reasons for the success you know i mean is this kind of paying off i mean is it this really good sort of poster child functional programming in industry that it will it will be fast enough and super fast i i wish i could say that functional programming was the last stand defense we had against global economic collapse jane street did well during the financial collapse for essentially two reasons one which i can talk about one which i can't and the one i can talk about is that the business they were doing which is high frequency equity trading and delta one arbitrage um basically wasn't strongly affected by the crisis you know i mean it's that that is probably one of the larger reasons why they did well okay so fb certainly hurts no functional programming did not cause the global financial crisis i will say because actually the co-founder of my current company um where we are actually now getting into some solutions that we're looking at scala or haskell launched the derivative studio trading desk at one of the larger banks so you know my partner actually did cause the global financial crisis so something we talk about uh somewhat regularly so if you want to come work for a really cool startup where you can you know see the inside story of what happened doc bunch would love to talk to you all right all right and we'll get to that uh in a moment uh so i and now uh on to the yes i mean that's i think i find it very fascinating i think uh uh i met max at the scala meetup and that was one of the things you should really be interested somebody really doing a startup when you thought not just talking about it and in fact i mean i've seen an aurelia book coming out on this and i thought that the very fact that early point now the book like this is already a sign of courage uh and somebody is basically endeavoring to to to to do a framework for startups and hoping somebody will use it and i mean now i see that it's actually um there is there are several so so i mean can you tell us how this came about and and basically uh in separate from from business trajectory what was it like in you know in the startup lifecycle to to from inception to to design the system to build it to even to maintain it uh what's your experience of the years old so starting with dusada me and my uh partner in the other startup he came from the ruby world so it probably did slow us down a little bit relative someone could have thrown together overnight and ruby on rails but it it wanted imposed on us a discipline to do things right the first way we didn't have this huge technical debt build up and so after you know maybe like a little bit of a slow down say total two three man months in terms of the prototype we actually found that we're much more productive you know the code was much safer so we loved it now when we started yasod was uh just about taking over 1.0 so it was actually i'm sorry no when we launched you said it was taking over 1.0 when we started you soda was at 0.4 so we were actually pretty intimately involved in the you know development process of you sowed um i was a young founder well not young i was inexperienced i don't want to say young it's not really true i was inexperienced and we kind of took a risk on a very new framework framework ended up being successful people use it it has traction but there were a lot of times we did make changes because of that i remember one version transition went from 0.5 to 0.6 i think and changed one of the underlying string management libraries uh literally just to upgrade to the new version of yasod it would we had to change 1200 distinct points in our code base which you know i don't think our code base was much more than 20 000 lines um so that was a little frustrating but you know a lot of vim grep is the artifact of haskell having separate uh several string classes and basically the way so this is kind of unique to haskell however after changing after changing the code in 1200 places somewhat manually we didn't have a single regression book nothing went wrong no test broke it wasn't even like we compiled we ran the test test failed right again it was once it compiled it worked before yes um and that that was like one of those like aha moments this is pretty amazing and that was a good thing you know with two of us it was hard to it ended up being a relatively complex application and just to have this very well-defined behavior to understand every action that we were doing in the system um really helped a lot so you know all the time they might have spent on like automated testing we're able to skip a lot of that in a sense and still have an incredibly robust solid product so that's i mean i think uh sort of there is like a honeymoon phase when you when you write a code base and it's new and it's fresh and then you then you finally in production and then you have real users and you have completely different set of uh expectations and if you want to make deadlines and often people cut corners and then just say you know i want it to work i don't care how but you know we should support this feature of this this bug should go away so forth so so what was it like in you know in the face well the first thing i would say is that one of the advantages of having really good technology and a really bad business model is you tend not to have a lot of users and your kind of unit user per unit technology is very low so that problem was kind of solvable um but actually one thing that i really liked about it was exactly what you said there is a temptation to cut corners you just throw this feature in a hospital and especially a sewed with the you know discipline that it would force on you it kind of prevented that um so it might slow you down a bit but as i said it really prevented this large accumulation of technical debt so you know it's one of those things that in the moment can feel frustrating but at the end of the day you're glad you did it uh so in terms of in terms of monadic i io right i mean i think that's the barrier to entry for most uh beginners and i mean web is nothing like you know io right i mean you're you know the users are doing something and and then you output the results back at them right so so uh i mean i looked at uh a little bit so but i don't have like a deep feeling what what it means in terms of you know the whole application so can you talk to it a bit like does it does this flow uh resemble ruby on rails or is it actually making a different enough so i mean when you talk about monetica you bring up a larger class of issues with functional programming in the large and especially haskell which is taking concepts that aren't that difficult and making them as esoteric and unapproachable as possible uh i firmly believe that if haskell basically forked itself and renamed monad's two contexts and a couple other word substitutions it would have five times the adoption uh you know the way um somebody my co my partner in this company didn't really do much hassle beforehand into the time a little bit and the way i trained him was i didn't go through the derivation of the statement you know we didn't go through you know working out all the monetic rules and verifying this and you know the theory we just said i need to do this how do i do this given this you know components what is the behavior so and that's fine and it's not when you think about it that way and you separate out the lingo you separate out the category theory it's not that difficult um there's a slight things can be kind of like an inversion of control and you might have to think about your entry points a little differently but if you think about ruby on rails or any web framework there's so much kind of inversion of control anyway yes you know you're not writing a pro you're not you're not writing a program that kind of steps through a series of commands you're essentially building functions and some libraries you're plugging in a big flow and the flow is defined as a convention for you yeah you know i actually think in the context of a web application it almost makes more sense however in general i think that monadic i o and all the all those issues are something where the terminology and the aesthetics of it for lack of a better term make it seem much more unapproachable than it actually is yeah it makes sense actually i mean the way you described it how you you you trained your co-founder actual sounds almost like the way i i picked pieces of it which i needed right because i i learned haskell and uh in the context of actual practical application you know uh analyzing actual live twitter graph so i you know and i wanted to compare haskell and closure and skull and also i just needed to do things so basically that's exactly the way i approached it and i'm actually now i'm curious you know if you have a good way to train people you should definitely formalize it and make a little a little course right because that's i mean that's i think how software engineers learn they they learn in a series of patterns and the simplest is a textual pattern and you see hello world so if you learn you know if you if you have a good way to present the spatterers you know how to do things with something other people call manas but they're really contexts and that that actually would be a great you're the one with the education company yeah so we'll definitely should talk about this uh you know i feel i almost feel like it's it's it's almost too intrinsically obvious and the community is doing something wrong you know if i want to teach someone how to write java and i'm going to explain how a try catch statement works i'm not going to get into uh processor interrupts and stack rewrites and context switches and all that i'm going to say you write some code and if it throws an error then you have to catch it that's right you know so it's something that everyone's doing anyways in haskell people say no you know forget that yes we're gonna do it this way that has never worked in the history of teaching anything ever yes uh you know and hope that somehow it's different um you know it's actually this brings up an interesting issue within haskell which is kind of unique where you have this really uh the split in the community where half of the people i wonder if they've even actually compiled their code or if they're just worried about compiling their law tech and you know writing papers you know you have this academic side which is purely focused on you know academic research and all that and then you have the industrial side which is different and more in the more recent language yeah it's more recent there's this tension however it's tension that i think serves the language well um you know there are downsides to it for instance the way most people approach teaching haskell however i think that you know in the end this is what makes the language so strong you know this is why they were able to implement software as a transactional memory in a weekend yes and if you think about all the effort that's gone into that and uh you know for java you can't because you have no immutability control right you know we're in haskell because they kept the purity because they had this academic ideal of a functional language they were able to implement it in a weekend i wonder you know i remember you had this controversy with michael snowman by wrecking the prelude and i'm wondering if maybe you can uh uh relate this episode and i wonder if there is any teachable moment there about the haskell community or uh is it shedding any light on how it works now you're getting in trouble um so all right here's the background the uh the haskell core library it's called the well the core core library is called the prelude it's the implicit import and every function yes and prelude has a lot of functions you know like to find the head of a list or to find an element associated map or associative list which are unnecessarily non-polymorphic you know if you think about you know like to see if an element is a member of a map or list there's no reason that has to be a list like you know rather than having to import the data.map version of the function and the data list version of the data.set version why not just have a polymorphic function because there is actually a type class that represents that they you know run off of that right so we felt it would be um more productive you know if we had a fully polymorphic prelude where rather than having to you know go through and change your importance to your functions you just you would change the data past it because a membership is a very basic operation exactly i mean if closure does this why not host them exactly what we did not do is when we released version .01 of the library write strict algebraic laws describing the behavior of each function um associated library now there were intuitive laws you know we know what the member function does but you know there's all sorts of corner cases and um certain elements in the community felt that this was a complete affront to the mathematical beauty of haskell now i think part of the problem is well okay there's two complaints one one issue was that the algebraic laws the other was that it would make error compilation errors much harder for especially beginners to understand which is absolutely true there's nothing we can say about that you know we weren't proposing this as a replacement to the current thing we just said you know for power users we think this might be more productive we picked up a little bit of flaming from the community more than i thought actually um so i think one of the things that we should have done is just make it clear that we weren't trying to replace anything people are afraid we're gonna replace it libraries we're gonna use this prelude and then be incompatible have this kind of like infection where you you couldn't have a library using the classy prelude and then a normal library right so i think we should have made it clear that it's not designed for libraries it's designed for you know end products you know and we're not trying to replace anything this is just for power users so definitely mistakes we could have made however you know i think michael snorman had um sorry he's the uh the developer so you know classy prairie and even though i love you so you're so is very dependent on little dsls so rather than programmatically defining your uh you know orm your database rm or your html templates uh there'd be like um or your routes even there'd be a little dsl that you would write them with so it ended up being much more concise clear it was still statically type checked you know beautiful some people felt that that was not the hassle way it was non-pythonic but whatever it was not haskell-ish um i i just agree i think dsls are a huge strength of functional programming languages um people accused him of trying to like change haskell which i thought was it struck me as one of those comments that people would make when they haven't actually used the framework they just read blog posts about it um because when you use it you find that it's it's much easier to define your routes the way you know with using this dsl yes this type say if you're yes and type save urls or wonder i wish i had them now yeah i mean it's actually strikes me as a great idea which now any other framework i use should use them right now and that i mean i think closure now has some notion of i mean i think this this will spread right that's the pioneering thing but what you say about the community division about the beauty actually to me the software engineer polymorphic prelude is beautiful right because i don't want to care about number multiple membership methods so i'm really curious the fact that somebody would think it not beautiful means they're holding on to this you know uh algebraic properties which which i i can't see anything beating compression minimalism in production right so i think that actually probably talks to these two different uh roots uh and and i think it's interesting it's interesting to me uh but the fact that they were afraid that it's gonna be a replacement means it was close enough to become a replacement if necessary and so i mean i mean basically it could have been that that if it were actually a real option right and and then and if if prelude is a is a library haskell right it means means that can be replaced the definition of a libraries you know you can take another library so so if you know if husky treats it as a library you know i think it's upper graphs you know to to treat it as a leper so i don't see it you know problem there i do just want to make sure that it's clear that even with this tension the haskell community is one of the best communities um for any language that i've used you know even with this tension if you ask and there's a couple of beginner questions a guest asked almost daily you know the the the listeners are incredibly helpful you know it's rare that you can ask a beginning question and have the father of the language answer it yes you know they're very helpful the community is great and you know the academics if you go along with their assumption that we're trying to replace the default prelude i could understand their trepidation of having a prelude without algebraic properties yes which were later introduced and now we have them in stores okay so do you have it i mean can i use it now i mean i'm just kidding if i was brilliant you could use it when this controversy came out um you know it's that's the nice thing about haskell is you never have to be really afraid of using uh you know pre-release libraries you know the type system saves you a little in a lot of cases um you can use it now i i haven't been that involved with the project lately i've been involved with this uh new project but there's no package uh i think so i know it's on github i mean that actually that's the biggest problem with haskell right now is hackage and package management and how is that i i'm subscribed to twitter stream and i see like a majority it seems like majority of contributions to packages from michael's neumann because i see like he's committing all kinds of things all the time and they're not like they're foundational like there are strings libraries and html libraries and all kinds of things right so i mean obviously somebody's committing to it so well now michael snowman is um uh part of fp complete i think fe complete so you know they're really getting behind it and doing a lot and i think they're trying to drag haskell into being a productive environment mm-hmm so package is alive as well right like that's the way yeah no it it works i'm just saying as a package manager well not just package but cobalt and package are one of the uh score points in haskell oh okay um again not to denigrate the people who've written them they solve some really hard problems but you know just they've been around for a long time so are they are there some features which are not supported uh you just get um like dependency management is probably the big um i mean they support it and they're actually very strict about it so if you actually satisfy your dependencies but sometimes you get a weird cases where the dependency management is a little off you know having said this again i've been outside of the haskell community for almost a year so i don't want to give away information yeah okay cool uh so so sort of uh kind of uh going back a bit to your um uh singapore startup i mean it actually is pretty interesting to me that you solved you had a mobile component which you were solving with eso so it's actually sounds like a very appealing feature and i think that html5 and phonegap uh wrapper sounds like the excellent first step you know people would use this so uh i mean so you basically you have you know under you'll build this architecture where you have the assault framework you have the mobile app i mean you you can almost like next week talk to any vc in san francisco and offer them a solution right because you know now if you know how to make a startup processing cards and have you know a little mobile app right so to me uh the beauty of this uh of the uh of the things is abstraction so you basically have a framework you know how to serve a mobile app i mean what prevents you from basically taking this and making the next startup you know in two weeks or i mean is or is this actually a working solution is this abstraction enough uh that you can you can basically because you you should probably have user management right you have some kind of uh monitoring you can run in production probably hopefully you can know like what kind of load you are handling so i don't know what the ops part of this right how can you scale maybe we'll even we'll talk about this after but is this an abstraction is is a haskell abstraction powerful enough so you can abstract you know what is actually startup doing take the most of your code and your mobile app tomorrow and make another startup with that so i guess your question is can you make uh something like a heroku or a parse for startups to run haskell yes um and that's something we actually thought about a long time ago one and we're getting well well away from the technology here and this is uh i have to put on my you know ceo hat on my vc hat um right now mobile html5 is not cool um i strongly disagree with it i think the reason is because facebook app version 4.0 was written pretty poorly in poor html5 and then they had a very well written um native app so everyone said oh look the native facebook app is so much better than the h150 whereas i i kind of think that it was more like a very well written native app it's better than a poorly run html5 which no one's going to argue it however that's definitely set the tide against mobile html5 apps um i haven't seen anything in the facebook app that seems like it would be impossible during html5 and um yeah century guys even implemented you know a good chunk of the functionality and pure html5 without a phonegap rapper um having said that i have a friend who's on the facebook mobile team and he claims that they tried and it was impossible so i could be wrong um i i don't know i mean i i think html5 is still a great solution and i think most of the stuff that's being done in apps does not need to be done in apps it's done in apps for reasons like monetization push notifications things like that which you can get with phonegap um you know i i don't think there's a huge demand from startups who want to have like a mobile app you know where they can ride their backhand in haskell you know it seems like a company like parse which goes the other way parse provides a back end and you get you can write the front end you're you know android or ios it has been fantastically successful so i think technologically you could do it you know no problem you combine it with aws or actually we're using microsoft azure now so little shout out thank you microsoft i never thought i'd say that but azure is actually really nice um you know i just don't see the the demand for that uh but i mean still uh in terms of uh in terms of uh you know high skill shell right i mean basically even even if not you know as a as a hero like service uh i'm just wondering about the power of abstraction right because you you in in in haskell the person is so high you can basically say you know you can abstract the things you users are doing without really caring what they are right you can have like a startup on ad right which is basically mediating between buyers and sellers of x i mean like 95 of you know simple startups so you know you find some kind of middleman position the tourists are visiting your city and you have attractions or you know readers are reading new streams and you find the tail or combination of them right so basically you position yourself in the middle of some kind of resources resources are customized for users right it strikes me as you know this can be expected or you know properly with tools so so so you so you mastered this you know you did all this hard work and you know of building startup i'm just wondering how reusable is it to you you know for this kind of like if you have to do a consumer facing start up in the future would you now dig out your ears out cold and would you try to fit it uh like do you feel you left it at the quality which is enough the difference between me digging out my said code using my next project and packaging that up as a platform that i'm going to start other people right um you know i i would use that for me personally yeah that's my question however i'm not sure that there's any business in selling it yeah i i don't see where the demand would come from um you don't see startups clamoring to do that i think if you had i mean maybe this is what the meteor guys are actually trying to get to um something like that but it was actually abstracted away into node or um or ruby or something you might have more demand again i think haskell is a better platform it's just you know where's the demand and you know in our current startup uh documents.com we you know i love haskell and i love scallop uh we actually built a prototype in coffeescript node and that was just because i had a co-founder who was not super technical but he actually taught himself decent amount of programming got a master's from stanford so just so we could you know get it out we did it in node and coffee script so we are moving on from that now yeah maybe you could tell us more about the munch and what is it doing and like what's your current startup experiences okay so doc munch is a private data cloud for finance professionals so we you know if you think about data that people in finance deal with 90 of the time they're not dealing with what we think of as big data you know small data sets they get from like analyst reports broker reports uh hedge fund returns things like that um you know the problem with big data you know dealing with stock prices security prices returns that's that's a soft problem in a sense yes but there's this other set of small data you know broker sends your research report with a bunch of like mortgage delinquency rates you want to pull out that table so what our system does it lets you extract data from pdfs excel files powerpoints store you know single tables and charts and data points in our cloud anytime you you know upload similarly structured documents maybe every month you get a report you upload it once plot data on next time you upload it same data is pulled out for you straight data in the cloud so you can then access it very fast and easily in you know excel via an excel plug-in so our problem is this like document structure analysis you know detecting what is a table what is a paragraph tagging all the data presenting it letting users share it and collaborate so they took a workload at a bank where a a research analyst might you know calculate some model figures or numbers coefficients and they generate a spreadsheet that they email to a trader to execute trades on or email to a client to trade on we're trying to get into that flow so rather than emailing a spreadsheet you'll you know put it into doc munch and then the traders use it straight in dock munch okay so this basically it's evernote but with much deeper financial data centric data centering yeah so we will actually look inside of the counter so actually strikes me as a very interesting uh uh application because a lot of these things will be recurring right so your broker report will come regularly so you only need to invest once and at this point you probably shouldn't shy away from using human intelligence right like if you know if the user actually will point out what he wants and you'll assist them right exactly right then they basically you can learn what they want and then and then you know and uh you mentioned azure uh i sort of am a secret fan of f sharp and and in that case you know i think michael did the excellent job and uh and uh i remember sharp uh advancing uh ahead uh beyond a camel in one of the aries type providers right the type provider is basically you can specify the type of an incoming uh data stream and and and essentially you only need to do it once and then then because you know you can be reading some weird csv table which maps into your structure type in certain way so you basically may specify it once you know what the first line is like and then basically uh the you know like you should check that the type is a bait right so so it almost sounds like you will each of your data streams will will have a type if it's recurrent right so you can you can actually you know say what the type should be like and then they can actually use type checking to see if that's like i mean it just strikes me that actually it maps a pretty bad functional model um so uh and but i mean i'm curious right obviously it's a lot of uh it may involve a lot of computational intensive things so so what kind of uh what kind of thinking are you doing in terms of uh uh processing right so i mean obviously coffee is an excellent choice for front end and we are using it ourselves and i think it's a fairly standard model that front end is now in done in in javascript the computer installed in the browser you have rich uh apps where you can interact with content you know it's a coverscript is excellent for this but you know come you know if the time comes to analyze it uh you know parse it you do language extraction now there is a lot of libraries done in other languages so like what is your thinking like in that sense yeah so we're balancing a couple issues there you know when we look at the contenders for what we want to base our you know heavy back-end processing really uh scala haskell um go is up there even though i'm not a huge fan of the language but the ecosystem is amazing and the tool chain is great there's a language coming out of mozilla called rust which i'm actually very excited about it's just it's not quite ready yet rust is a if you took c plus plus and haskell and they had a child and the child wasn't a horribly mutated freak it would look like grass rust is uh i think of it as like c-plus plus but with you know controlled essentially mostly immune immutable data structures control immune ability highly high concurrency very strong static type system you know it's like simple specimens haskell it's great it's just not ready yet that's mozilla's actually writing a next generation rendering engine called servo in ross so i think it's great and i just wish they were about a year further along those guys are doing really incredible things so you know so we're looking at something like haskell versus scala vs go you know we're comparing the the obvious thing is that we're comparing library availability productivity but we're also comparing things like recruiting you know one one thing we learned from jane street and it's been true in my pr my previous startup is that if you put out a job request for haskell developers you will receive between one and five percent as many replies as you will receive if you ask for java or javascript developers however of the you know that one in 100 guy that replies you can be almost certain he's a smart guy yes uh there are very few dumb asses replying to haskell jump those things yes so you've got an incredible signature noise ratio and i think haskell's on top and then you've got you know scalas up there too and i mean problem with rust as someone's actually heard of it and then go it's going to be a little lower and then you get you know your your javascript and python and c-sharp and ruby is ruby's under the table um sorry i just can't stand it so so that's basically a great self-selecting filter for recruiting right so that you and that's really one of the unsung features of the functional programming uh the other thing i just wanted to say is you mentioned how microsoft did great things with f sharp and one thing that not a lot of people are aware of is that microsoft is actually developing two functional programming languages one is a sharp and the other is haskell most of the work on ghc and the core libraries has come out of ms research so you know if someone ever says why are you using you know some crazy exotic functional programming that just has school you just say well no one ever got fired for choosing microsoft right exactly it's a microsoft tool yeah yeah basically i think it's great that microsoft actually supports uh you know that and that's yeah i think i think i mean i met with uh the developer division i mean the shortfall because i think it's a lot of smart technology being developed there asia actually tried it along with f sharp because i think f sharp is an excellent gateway and uh and they're trying hard to actually make asia useful from f sharp so so i mean first time my kids do you have a choice yeah so originally actually they wanted uh f sharp was going to be haskell the problem was they they just couldn't get the laziness to work right on the clr which is why they end up going with oklahoma which is even if superficially relatively similar to haskell because it doesn't have the laziness by default and some other uh exotic features that haskell has um they were able to you know get it on the clr much more easily yes and actually i mean that in my mind is is is a problem with big data right because i try to process twitter graph with haskell process process twitter graph right a very huge data set and essentially what we ended up doing if i represent my graph as a map uh and the map is lazy it led to all kinds of problems in high school so essentially we had to strictly if i had to go and add banks everywhere and essentially then i got a camel so so you know then basically it sounds scenarios laziness uh is not easy to work with i mean i'm sure in deep theoretical sense it's always good but in this practical sense you know you have this huge graph and you need to do something with this uh you need to realize that that was not trivial you're preaching to the choir on that one a conversation i had with uh michael norman actually um dso developer is that in addition to forking haskell and changing the word monad to context uh we felt that a uh strict by default version of haskell would essentially solve 99 of the problems people have and that's almost where i see rust going is it's kind of the strict by default version of a haskell and the reason they have the laziness is well in addition to the academic research that was what they needed to get monetic programming working you know magnetic programming cannot work without lazy semantics so i think closure strikes a good balance that is the sequence is so lazy and map is lazy so that's a very typical beginner problem right but but because it's in this context and you know everybody everything derives from sequence then you have essentially lazy processing of of streams for free you don't need special synthetics for that and and most everything else is is strict so i think that maybe that's you know that it definitely makes high school cause a lot of pro and we we had problems with the two i mean i ever in some trading systems in high school and the laziness killed me yeah i mean it's it's makes your code very difficult to debug at least it doesn't somehow sound right for the high frequency trading uh so uh so interesting i mean i i'm actually a bit surprised at your uh conundrum in terms of uh libraries right because i mean all kinds of machine learning and especially language processing i think i don't see multiple choices anything which with jvm right because i mean there is a lot of libraries for language processing i would say that if you look at language extraction the competitors will be python which is used by a lot of uh computational linguists and and so python and and java right you have basically two choices here so i think haskell is popular in the theoretical sense there are some cute libraries i mean it's it's science it sounds like something which computational english would pick but it actually i think is a bit too much esoteric for some of them so they actually settle for python in my kind of uh general general uh uh view of this and and so i was looking around you know i want to do an lp in haskell right i want to sort of do two cool things you know i like let's say you know and i want to sort of survey the field and i actually don't find many of rascal libraries for nlp uh right so a lot of them so you you probably can wrap a lot of c libraries and not but whatever is there right but again computational scientists linguists are not doing this in c so so it's it's almost like you know you'll be interfacing with python or or jvm or jvm you know if they wrote it in java you can pick it up from scala closure one of the strongest uh arguments for scala and uh so and i don't foresee anything in rust or or go you know so um so i mean the only reason i see you even having this choice is like the practical um the practical and pragmatic approach is often you end up writing everything yourself a lot with yourself right so like i mean if it sounds like you you guys are ready to just you know write a bunch of stuff yourself yeah our nlp needs aren't that heavy um we've actually uh we outsource a lot of our nlp to a provider um called alchemy api which is just some pretty awesome work uh for us it's more the document structure analysis so there's a little bit of machine learning in there but because it's kind of an unusual problem that not a lot of people really put a ton of energy into solving there aren't a huge amount of libraries available um you know machine learning like classifying elements on documents that'll be a big thing but you you hit the nail on the head with uh libraries and scala and that that is the principal advantage of scully and you know there's what we talked about like uh someone should write it something like coffeescript to translate the uh the haskell syntax into scala would be would be wonderful yeah so i'm curious about the choices i mean i hope once you finalize it and your uh uh dog punch is underway we'll have you back and you can tell us you know what what's going on with how you you pick uh that uh that other choice uh so thank you garage for coming i think it was it was great having you here and we definitely wish you a lot of luck in in uh in your new startup adventure and uh hope to see you soon you know tell us more about your technology experiences great thanks for having me