From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E22807EE51 for ; Fri, 24 May 2013 16:43:37 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkDAKd7n1HAbSoIlGdsb2JhbABZhnO5Q4UiBAGBBBYOAQEBAQkLCQkUBCSCIwEBBSMPATgOEAsJDwICBQwVAgIPBRhEiA0EqHaRfBaBEIxggRcHCgyCKzJhA48HhGODUJRS X-IPAS-Result: AqkDAKd7n1HAbSoIlGdsb2JhbABZhnO5Q4UiBAGBBBYOAQEBAQkLCQkUBCSCIwEBBSMPATgOEAsJDwICBQwVAgIPBRhEiA0EqHaRfBaBEIxggRcHCgyCKzJhA48HhGODUJRS X-IronPort-AV: E=Sophos;i="4.87,736,1363129200"; d="scan'208";a="18867751" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 May 2013 16:43:37 +0200 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178014212.adsl.alicedsl.de [85.178.14.212]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id r4OEhZkO004268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 16:43:36 +0200 Received: by first (Postfix, from userid 1000) id 9E1BB154066B; Fri, 24 May 2013 16:43:35 +0200 (CEST) Date: Fri, 24 May 2013 16:43:35 +0200 From: oliver To: rixed@happyleptic.org Cc: caml-list@inria.fr Message-ID: <20130524144335.GF2007@siouxsie> References: <519F1CF6.7050007@riken.jp> <20130524123551.GA7605@ombreroze.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130524123551.GA7605@ombreroze.happyleptic.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] French study on security and functional languages On Fri, May 24, 2013 at 02:35:51PM +0200, rixed@happyleptic.org wrote: > > 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. [...] This reasonable critique has lead to a lot of modern forms of development which means to a programmer, to change the overall direction of a project from week to week. "Oh, we have not taken into account the following", because no planning or market research or customer inquiry was done in advance. Instead of this minimal planning, in the middle of the project anything will be changed... ...more than once... and the project will take a multiple of the time that was first talked about. So, it's not always the bad specifications. It also can be missing of specifications, or missing of the overall goal of a project. So, there are many causes, why a project can be handled ugly... To follow a specification is not eveil in itself. Ciao, Oliver