Objective Caml’s use as a web programming language is very limited. It’s orders of magnitudes smaller than the mastodons that are PHP, Java and ASP.NET, and also considerably smaller than Perl, Ruby and classic CGI solutions.
Why?
Hosting Availability
I’m discussing here only the cheap hosting options provided to the vulgum pecus. Since people at hosting companies don’t see Objective Caml as a credible web language, they are not going to spend precious time providing support for it on anything but user-maintained dedicated servers. Arguably, this one affects other languages as well. Looking at my host’s prices:
- PHP is available around €2/month
- Perl/CGI/Python start around €4/month
- Anything else needs at least €12/month
Sure, I can look for .NET hosting elsewhere (starts at €4/month) or a Java-Tomcat combination. But there are as of now no “Objective Caml is installed and you can just upload your software” services. The only one that’s commonly available is CGI, but it requires compiling the program natively (since there’s no runtime), which requires a lot of knowledge that’s just not needed for PHP.
This means your average web beginner who wants a website will not have access to much beyond PHP.
Beginner-Friendliness
In this regard, PHP is the easiest by far (along with Perl or Python, but these two have fewer highly targeted tutorials available online). You don’t have to launch an IDE to manipulate your code, you don’t have to run a compiler, you just open a file in your text editor, upload it to the server, and visit the URL again.
This method has massive downsides. First, it’s not practical for any kind of industrial development (you would have to move to an IDE, use source control, and set up a deployment strategy beyond just uploading the files). Second, the absence of compiling means a lot of errors can filter through and only manifest when a certain set of conditions appear, even though it’s a stupid error that a classic type system could have caught.
But it’s practical. The cost necessary for starting to work with PHP, or to hack through a small bit of existing PHP code, is orders of magnitude smaller than that of other languages including Objective Caml.
Web Frameworks
Ruby has Rails, PHP has the Zend Framework and CakePHP, C# comes with ASP.NET, and Java has (among others) JSP and JSF. What does Objective Caml come with?
- There’s no universal mapping system that would map Objective Caml values to a database. You have to work with specific tools: POCaml (postgreSQL), OCaml-Mysql, and so on. Arguably, that’s not so bad.
- There’s no universal HTTP handling. On the one hand, there’s OCaml HTTP, which runs a daemon (can be nasty on non-dedicated hosting) and is GPL software. On the other hand, there’s mod_caml for Apache, which benefits from existing Apache installs but runs every program as a CGI script with no persistence outside of the database. And then, there’s godi-ocaml-http.
- A lot of the additional functionality provided by typical web frameworks is missing. Take a look at the Zend Framework or Rails to see the amount of web-oriented functionality some web frameworks manage to cram.
In short, there’s not a lot to see here.
What If?
What would happen if a compact web framework were proposed? One that, in addition to borrowing existing useful concepts from other languages, also added some OCaml-specific features to the mix. Functional modules would be an interesting addition, so would be the type system and pure functional programming applied to transactions, and monadic optimization at initialization time would also be quite interesting.
The problem of convincing young web beginners to use the language would still exist, but at least professionals could look upon it with a little bit more seriousness. Especially if some standalone high-quality pieces of web software written in Objective Caml hit the market.
So, where do we begin?
Hi. I'm Victor Nicollet,
What about Ocsigen/Eliom? ( http://www.ocsigen.org )
I would have mentioned it. But the link didn’t seem to load on my computer and I didn’t want to post a dead link. Maybe I’ll edit the post if I manage to load it.
Ah ok, curious to see, what you’ll write when you can access Ocsigen’s page.
Regarding your “what if” question, I don’t think much would happen. The OCaml community is too “silent” (in a good _and_ in a bad sense) to be much of a match against the Ruby, Python, PHP etc. communities.
If you’re accustomed to the buzz and polished presentation of before mentioned communities, you’d have to think that OCaml died somewhere around the mid nineties.
My main problem with Ocsigen (actually, with Eliom) is that it tries very hard to hide the basic principles of the web behind an abstraction. I find myself regularly wondering how the system would handle an exceptional situation that goes beyond its abstraction (the server hardware dies in the middle of a persistent data commit, the user loads several pages at the same time or simply fails to reconnect).
Objective Caml tends to be a “safe” language in that it shields the user from a lot of chaff to concentrate on the relevant concepts, but the downside is that developers are not accustomed to defend themselves against chaff that the language simply cannot shield them from.
Sorry for the downtime of ocsigen.org, the server hosting the site is *very* capricious…
I don’t know enough about Ocsigen/Eliom to argue that, but do you consider sane handling of extreme error cases a requirement for e.g. beginner friendliness? Or is this concern independet of you question regarding the lack of interest in OCaml as a web development language?
I believe that the Ocsigen server and the Eliom framework are simply fantastic. The OCaml/Ocsigen community is somehow too focused (in my opinion) on producing statically typed valid (X)HTML. But you can insert raw HTML if you wish to simplify quick development.
Then, to build a web application that is highly interactive, you can do really cool stuff with Lwt and the React module. In my case, the web app was handling interaction with an Asterisk server, and was used to automate dialing. Agents would use log into a webpage, connect with their softfone with the Asterisk server, and the webapp was administrating everything, automating calls coming in and out, and handling dynamically with (statically typed) ExtJS the status and outcome of phone calls. And there was another similar webpage for the administrator. All this was fully reactive (An agent event or an Asterisk event or an administrator event usually hd an impact on both Asterisk, the agent’s webpage and the administrator’s webpage), and happening mostly in RAM. The DB was just to memorise what was going on, and was not the heart of a state machine, as is too often the case…
Everything was done in a functional and reactive way. Took me two weeks, only evenings, to develop that.
Somehow, even a Ruby on Rails app is a state machine. Perhaps a “better state machine”, but a state machine nonetheless, in the sense that incoming requests interact with each other by modifying the internal data.
With Ocsigen / Eliom, it’s completely different: it’s a “safely” multithreaded, compiled, application. And that makes all the difference.
Besides, there’s O’Browser, which is an OCaml bytecode machine that is interpreted in Javascript. Meaning that you can run OCaml code in the browser. What would be cool is to have cool javascript libraries such as ExtJS binded to O’Browser: you could use really high abstraction for windowing, etc…
Much has been done for browser-side technology. On server-side, somehow, the “state machine” paradigm has been a hindrance. To some extent, Ocsigen and Eliom fixes that when using high level stuff such as React.
I really think you should have a look at Ocsigen / Eliom / Lwt / React and write another post after that. There are some caveats, and a steep learning curve, but overall, it’s really impressive.
I want to learn ocsigen,but it lack of document writed by chinese.
Ocsigen is really awesome. Now with js_of_ocaml, you can do amazing stuff like an online toplevel written in OCaml and compiled in js code.
Look also to the new hyperbolic three viewer.
Keep in mind that the article you are replying to has been written three years ago – and two years before Ocsigen 2 came out. I find the new version to be greatly improved, and of far greater technical maturity than was the case years ago.
But I still wouldn’t use it on a large projet (and, as a matter of fact, I am not using it on my current OCaml-based large project), for several reasons. I guess I should post my updated views on Ocsigen one of these days.