[erlang-questions] Two beautiful programs - or web programming made easy
Tue Feb 15 15:20:43 CET 2011
I just wanted to quote a few excerpts of Frédéric's emails,
because I completely agree with them (see below).
I think that if you want to develop good web applications, then
you need to know HTTP, and design the client-server interaction
around its principles and its stateless nature, i.e. following a
RESTful approach . The user interface elements (HTML, CSS,
dedicated knowledge and experience in order to get them right.
I also think that everything which tries to circumvent the
HTTP/web architecture in order to "help" the programmer reach
from the server-side to the client-side is doomed to fail,
especially when scalability becomes an issue, either on the
developer side (more than a few programmers are expected to
work on a project) or the client side (more than a few users
are expected to interact with a web application).
Just to make a few examples, I'm referring to "cool" stuff like
continuation-based web frameworks from the Smalltalk/Lisp/Scheme
reminds me of automatic SQL schema or query generation: it
usually sucks, and thus it is hated and avoided by developers
and DB admins who are actually proficient in SQL).
IMHO, it is an error to focus on toy applications (and/or
single-user applications, like the Appmon) and assume that an
useful solution (at least from the POV of a single developer,
or a small group) could "scale up" to real-world application
development. When projects start this way, and they grow,
they usually need to be thrown away and rewritten ground-up.
Here's a famous example: a few years ago, Reddit was considered
a proof that "Lisp works", because it was a prominent web
application written in Lisp. When the user base grew, Reddit
was completely rewritten in Python . This was considered a
"betrayal" by the Lisp community, and thus several developers
started to write "a Reddit clone in just 20 lines of Lisp".
Those were interesting exercises, but they didn't address any
of the problems of the first Reddit: they didn't scale,
didn't support templating, didn't support l10n or l18n,
dind't offer battleground-tested libraries...
From my experience, I can say that it's much better to
start from the complete and realistic scenario of a "real" web
application, and see if (and how) an approach that works at
this level could "scale down" and become "easy" in single-user,
single-developer scenarios. IMHO it's also the most effective
way to propose Erlang as a sound alternative for web
On Mon, 14 Feb 2011 07:43:57 -0500, Frédéric Trottier-Hébert
> The truth here is that most programmers are awful at design. In any
> somewhat large setup, your backend programmers, your designers and
> your integrators (the guys just handling HTML, and CSS, maybe some
> Right now the ring of web technologies is divided in a way that makes
> it somewhat simple to have different people from different background
> and knowledges to work on different part of your software. It makes
> sense to have the designer or integrator to be able to change the
> and feel of a website without having to play in your code and maybe
> mess up database queries. Modern template engines in fact try to
> forbid all kinds of seriously side-effecting code (like DB queries)
> from happening in the templates.
> not need to suddenly learn Erlang to be able to debug your
> Then again, this separation of concerns allows specialists to work on
> their speciality with more ease. It makes things somewhat simpler in
> larger organisations, but quite painful for one-man operations. I'll
> tell you that it makes a lot of sense when you know all of the tools
> in the toolkit though :)
On Mon, 14 Feb 2011 20:50:11 -0500, Frédéric Trottier-Hébert
> There is nothing wrong with what Joe is doing. There is nothing wrong
> the web in general and we shouldn't reinvent the wheel all the time
> because we might be coming from a different domain or we don't have
> the same experience as real web developers have.
Alceste Scalas <>
More information about the erlang-questions