Why would advanced programming languages matter in the world of Big Data? You may argue that large amounts of data need a lot of processing power, but really — modern business trends are bent on juggling data, not computing it. There are 3 kinds of operations that are predominant today:
But data is the blood of the virtual society, for good or bad. No wonder we have been enjoying the reign of data-oriented information technologies ever since computer science left the containment of academic establishments. And so there came “human-friendly” but not very efficient tools with relatively low entry levels like PHP, Perl, CGI, HTML, databases and SQL, web frameworks, Ruby on Rails, Django, Joomla, content and knowledge management systems, CRMs, ERPs, microblogging services, you name it. Although this proved to be beneficial to the development of information technologies, data-oriented software clearly marked the decline in computational complexity of the tasks that it had to handle.
So all this talk about the advent of functional programming, high performance, parallel and distributed computing, all those cool languages like Haskell, Clojure, Erlang, is irrelevant. It is fun and awesome, but useless until business demands real number crunching, instead of some data juggling on steroids.
I’m talking about trends here. Naturally, the world is not all black or white, 0s or 1s. There are computing-intensive projects today, and great programming paradigms find their use in those few business or scientific applications. Just stop pondering “Why [insert any over-hyped language which is less than 20 years old] will win.” It won’t. At least, not because it’s the fastest, strictly-typed, has a great virtual machine, better garbage collector, derived from Lisp or anything.
GNU/Linux toolset for CalDAV and CardDAV is abominable. It’s basically a bunch of PHP projects (and their derivatives) and a twisted python of Calendarserver amid them.
I don’t even want to dwell about what’s wrong with PHP projects. The choice of the programming language and all the “framework” it depends on, says it all.
Calendarserver is so-so, although I cringe every time *.plist format is mentioned. But its CardDAV module doesn’t work with KMail, the e-mail client application that I prefer. Or perhaps it’s KMail’s fault. Not to mention, the choice of authentication options of calendarserver is not particularly UNIX-friendly: either you store accounts’ credentials in a dedicated XML file or use LDAP. What about good old UNIX PAM or anything more secure and common, hmm?
That said, I started making steps towards implementing CalDAV and CardDAV in Guile. Lightweight, simple, standards-conformant, Linux-friendly, etc. Surprisingly, there Guile lacks quite a number of libraries that I could’ve reused. So I’m announcing my first step, a library to handle vCards. I’m aware that there are already libraries written in C for that, but I’d rather not deal with FFI, memory leaks and all that stuff now, if I want the project to see the light anytime soon.
Although it is not news for active Haskell programmers, the lovely world of cabal-dev sandboxing is making it into cabal. Not only that, but there’s a bunch of long-awaited features too, like specifying extra source repositories for locating non-hackage (e.g. local) packages, assets and “extra prog path” (now you can point it to where alex or happy binaries are found, although I’d argue that setting $PATH is not a good enough option). Anyway check out the upcoming features of Cabal 1.18.