Re: [Caml-list] Web Development with OCaml

[Jimmie Houchin <jhouchin@texoma.net>]

I don't know if what I have in my mind does justice to functional
programming or not as I do not fully have a grasp as to what that is. My
approach is somewhat pragmatic.

I would like to code in a language that is both fast to run and fast to
code in. I want a language with automatic memory management. I am not a
C/C++ programmer. I don't particularly want to program in Java. Nor do I
find Java too advantageous. Now that I've made everyone ill. :) ...

OCaml seems to fit the bill reasonably. The largest challenge to me with
OCaml is it has a foreign syntax (to me) and it is functional
programming. So I need to learn a new syntax and program
paradigm/philosophy. But the benefits for doing so seem to be there.

The strength of FP in my web application, from my understanding, will be
a simpler design. Most web app servers and such are OO and can be quite
complex.

In a simple direct comparison to Perl or Python it would seem OCaml
would perform better.

>From a pragmatic view if simple Python pages (non web app server,
mod_python, etc.) were served at the rate of 100-200 rps and OCaml could
better that by a reasonable margin, then it would be a big win. As tools
for OCaml web development mature and grow the win could become even
larger. Just thoughts, hypothesis, and theories. No concrete facts as of
yet. :)

To me if a Functional Language such as OCaml became more widely used for
practical, pragmatic reasons. It would still be a win for Functional
Programming and OCaml.

So yes, I could probably be using other tools but if OCaml out performs
them, then it is a reasonable pragmatic choice. And if I can end up
being a better programmer using a better tool, well... :)

I am currently exploring and evaluating my options. It just seemed to me
from surface appearances that OCaml could be an excellent, potentially
superior choice.

Hopefully in the near future I'll be able to put together some test
pages which I can use Apache/Zope, Apache/Webware, Apache/OCaml,
Erlang/INETS and see what comes out.

Just my thoughts and opinions. 
Thanks for your input.

Jimmie Houchin


"Alexander V. Voinov" wrote:
> 
> Hi
> 
> Jimmie Houchin wrote:
> > The speed and memory results in the shootout are amazing. But what compounds
> > it is the LOC result. To me that indicates that a language does not have to be
> > verbose to be fast.
> ...
> > Currently fast web servers like Tux 10-15,000+ rps (requests per second),
> > Apache 2-4,000 rps aren't dynamic (at those speeds). Dynamic website tools
> > like Zope, etc are either like 20-80 rps or some I've seen up to 100-200 rps.
> > This is a great disparity.
> >
> > I want a dynamic website which gets as close to static speeds as possible.
> 
> > 3. Tux module. Create an OCaml user space module for Tux.
> >       This would be interesting and would probably be very fast.
> >       This is also beyond my skill.
> 
> I'd like to seriously wonder about the impact of garbage collection in
> such a persistent module, which has to reclaim stuff time to time. And
> given that there will be many linked (recursive) data structures, the
> process of reclaiming would take time. Unless it may be run as a
> separate thread on a separate CPU, and the process of getting space for
> new stuff doesn't heavily depend on the collection of the old one (say,
> when it's not a problem to malloc one more gig). My suspicion is that
> the currently widely discussed shootout doesn't catch the effect of GC.
> 
> With all this I mean that you are to maintain a kind of _conceptual_
> cache in your dynamic server, like filesystem cache serves for static
> pages you mentioned, otherwise it would be little point to apply the
> strength of FP. Say, if you store your stuff just in a database, and use
> some WebDB, or so, you do not have to bother about FP. (But it all is
> complete IMHO)
> 
> Alexander
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr