From: rixed@happyleptic.org
To: caml-list@inria.fr
Subject: Re: [Caml-list] French study on security and functional languages
Date: Fri, 24 May 2013 14:35:51 +0200 [thread overview]
Message-ID: <20130524123551.GA7605@ombreroze.happyleptic.org> (raw)
In-Reply-To: <519F1CF6.7050007@riken.jp>
> The document "État des lieux des langages fonctionnels"
> is interesting even out of the context of computer security.
For non french readers: it's typical project management ideas from
the 19th century. The paper describes a vision of programming
projects that's old, erroneous but still prevalent amongst many central
administrations, where you first have some infallible specification
(it's not stated, but this probably comes from a comity of experts)
which is passed down to the programmers, and the main question that's
studied is "what tools should these programmers use in order to ensure
the code comply to the specifications".
Of course, anyone with any experience of how real projects fail in
practice will know that most often than not the fatal flaws are in the
specifications right from the start, or are introduced to circumvent the
rigid structure imposed by such specifications, and that if you want a
project to met its goal you have to question the overall process and not
merely the tools used by the programmers, which, independent on how much
some may be nice and others awful, make little difference in most cases.
Then the paper try to convince the reader that functional languages have
only advantages over procedural languages, citing our friend J. Harrop
from some years ago and other blogs.
Follow a rapid and honest presentation of many languages considered
functional, then a table summarizing the various opinions the author
have about some qualities of these languages.
For some time, there seams to be a new tendency to study scientifically
the various languages and idioms in existence. This LaFoSec project
clearly don't fall in this category. In my humble opinion as a mere
taxpayer, government funding would be much more usefully spent in
postmortem study of past projects, funding large experiences comparing
various tools or making an inventory of the current practices/tools in
the industry...
next prev parent reply other threads:[~2013-05-24 12:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 7:02 David MENTRE
2013-05-24 7:55 ` Francois Berenger
2013-05-24 12:35 ` rixed [this message]
2013-05-24 14:43 ` oliver
2013-05-24 15:15 ` rixed
2013-05-27 1:18 ` Francois Berenger
2013-05-24 14:35 ` oliver
2013-05-24 14:59 ` Esther Baruk
2013-05-24 15:05 ` oliver
2013-05-24 15:18 ` David MENTRE
2013-05-24 15:36 ` Esther Baruk
2013-05-24 23:13 ` oliver
2013-05-26 14:14 ` Marek Kubica
2013-05-24 17:44 ` Pierre-Etienne Meunier
2013-05-27 8:55 ` Fabrice Le Fessant
2013-05-24 14:47 ` oliver
2013-05-24 15:02 ` Johan Grande
2013-05-24 12:41 ` Olivier Levillain
2013-05-24 12:46 ` Anil Madhavapeddy
2013-05-25 8:53 ` Olivier Levillain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130524123551.GA7605@ombreroze.happyleptic.org \
--to=rixed@happyleptic.org \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox