On 2/16/07, skaller <[EMAIL PROTECTED]> wrote: > On Fri, 2007-02-16 at 14:49 +0100, Ramon Diaz-Uriarte wrote: > > On 2/16/07, skaller <[EMAIL PROTECTED]> wrote: > > > > Hehe .. and Felix started out as a competitor to Erlang > > > in exactly the same application domain :) > > > Uhmm. This is _most_ interesting. I see no mention of Erlang on the > > main page, nor on the docs I've been browsing. > > It takes time and effort to write good docs -- much less to > spout off in an email. >
Sure. No criticism in my email. And I am fully aware it takes even less time to complaint and ask for someone else to do the stuff :-) , so I offered my comments with best intentions. > I was employed by a major Australian telco software vendor > to solve a productivity problem they were having. > > Their key application was a Service Control Point (SCP) > program. An SCP is a computer which is connected to an analogue > switch to provide business services such as Freecall, Conferencing, > Pre-Paid Phone (the big money spinner), and other such things > that a dumb switch cannot handle. > > The SCP basically intervenes in the switch call handling > cycle on the one side, and accesses a database on the other. > > There is an Euro Standard for how to do this, amenable to > construction of the services with graphical building blocks, > much like a flow chart: the GUI is a major selling point > for the software "Look, you can design your own services!". > > Unfortunately the building blocks are primitive and the system > was designed by engineers with no understanding of software > construction .. there's no way of building real services > within the Standard. > > The company had an implementation of the Standard using C++ > classes .. which had to be painfully and manually hooked > together to implement a service. Pre-paid phone took 3 > people over a year to build. > > Now before I go on, a key feature of the system is that > hundreds of thousands of calls can be handled simultaneously, > roughly by keeping track of where in the flow chart you're > up to: a program counter. So context switch is very fast. > > But some services require things like finding an optimal > route for a call to calculate when a Pre-paid customer > is out of cash, and the call has to be disconnected: > and given various timezones, network topologies, > and plethora of 'products' telcos like to offer, > this is fairly difficult recursive exploration problem: > WAY too hard for the brain dead standardised model > to handle. > > So they wanted a LANGUAGE which could be used to implement > the business rules efficiently, but which could also support > hundreds of thousands of concurrent phone calls (threads). > > And, it had to sit on top of their 2 million lines of > C++ code which handled networking, events, management, > reporting etc (they used ACE, ACN1.1 compiler and other > such stuff). > > Ideally they'd have just used C. The problem is that the only > way to run lots of threads in C is to use stack swapping.. > and it is not only not certain to work in C++ due to > exception handling etc, it is also quite slow and horribly > resource hungry because stacks are linear and you have > to allocate enough (address) space for their maximum usage. > > So I wrote a program in Ocaml (GASP! Functional programming > in industry) which translated a basic language into C++ code, > but which *control inverted* the code so that whilst you wrote > algorithmic master code (read and write channels), the > translated code was actually event driven. > > [The company fell over in the .com crash .. ] > That's too bad. > I have redeveloped those ideas into a full scale language, > always preserving the C++ compatibility and high performance > user space threading capabilities which were the original > requirements. > > Today, I don't really seen Felix as a competitor to Erlang: > the models are quite different: Erlang is purely functional, > does message passing, is process oriented, and dynamically > typed, whereas Felix is imperative, shared memory, statically > typed. It's more like they're complementary than competitive. > > Felix would be used to create high performance > building blocks that Erlang would manage at a higher level. > Ahaha. Thanks a _lot_ for the explanations. I was completely missing the context, and your last two paragraphs help me understand the differences better (I was obviously confussed here). Now, following with the tradition of "it is sooo easy to ask for stuff": my superficial understanding is that distributed, concurrent, and parallel computing using shared memory can be a lot harder and error prone (e.g., "Concepts, Techniques, and Models of Comp. Progr", from van Roy and Haridi). If at all possible, when/why/how to choose Felix over Erlang (or Oz) and how to complement both (your sentence of "Felix to create ... that Erlang would manage ...") would be something great to have in the docs. Thanks a lot for your detailed email. Best, R. > But then, I'm not an Erlang programmer .. but it would be > cool to have a paying contract to actually do some of this: > Ericsson would make a cool business partner .. :) > > > -- > John Skaller <skaller at users dot sf dot net> > Felix, successor to C++: http://felix.sf.net > -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
