Returning to the point of a "compelling case" to implement TCO. Lots of EU banks and USA banks are running Linux and are heavy users of C++ for their quant work. They build their models in a variety of languages like Python, Haskell, OCaml, R, etc, then go all the way down to C++/Java for efficiency. I've already seen some interest in F# from the financial industry, but the fact that it's limited to Windows/.NET discourages these people to take a further step.
>From my point of view, these people are tired of Java and C++, they would rather be deploying their models directly to production in a single environment. With a good, fast and stable implementation, I think F# has the strength to bring that. Microsoft is not building F# because it's a pretty little thing, they are trying to bring a strong platform for financial and scientific industry. Best regards, Diego Frata [email protected] On Sat, Jan 30, 2010 at 11:00 PM, Alan McGovern <[email protected]>wrote: > Hey > > On Sat, Jan 30, 2010 at 11:08 PM, James Mansion < > [email protected]> wrote: > >> Alan McGovern wrote: >> >>> Feel free to contribute the changes required to remove the limitations on >>> when/where mono performs TCO. That would allow you to contribute F# patches >>> if you wish. >>> >> I'm intrigued - why say that? I mean - what's the point? What are you >> trying to achieve, really? >> > > I say it because he expressed an interest in contributing to mono in the > email I responded to. He is also, by his own word, quite familiar with VM > technology in general so he'd be an ideal candidate to contribute a patch if > he wished to and had the time to do so. He also appears to be quite familiar > with TCO so he'd know all the cases which would need to be deault with. > There is no ulterior motive here. > > Alan. > > >> If someone has domain knowledge and implementation skills on top of CLR >> but can show that Mono is defective, its efinitely reasonable to ask them to >> give 'the mono development community' a test case and bug report. >> >> But expecting them to climb the mountain of learning to fiddle with a >> particular CLR implementation's core is nuts, particularly when they have an >> alternate that works for them to do their day job. If someone wanted to >> climb that mountain and make the changes, then presumably they would want to >> start by reading the copious up to date detailed design documentation and >> implementation notes on how (and why) it works now, so that they could size >> the task. Oh wait ... :-( >> >> Its much, much more efficient for someone who already groks the internals >> to make fiddly low-level changes, particularly if getting them into the >> release stream requires a lot of trust relationship with the release >> masters. I think you do a huge disservice to everyone by trying to get >> outsiders to work on something like that - or perhaps you just want people >> with bad news to go away so you can paper over the cracks? >> >> Please, ask for test cases and reports. FWIW I suspect (justa hunch, I'm >> certainly not an expert) from what's been said that if a calling convention >> change is needed (and I seem to remember there are some issues that prevent >> fuller use of LLVM that one might also want to consider if that sort of >> change is on the cards) then its as much a political and >> major-version-compatibility issue as it is technical, and once again asking >> someone to work on patches in such a situation is laughable, given the >> degree of risk that they might completely waste their time. >> >> >> James >> >> > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > >
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
