From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,f3bebae566a54cab
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!usenet-fr.net!gegeweb.org!aioe.org!.POSTED!not-for-mail
From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?=
 =?utf-8?Q?=29?=
 <yannick_duchene@yahoo.fr>
Newsgroups: comp.lang.ada
Subject: Re: Some exciting new trends in concurrency and software design
Date: Thu, 23 Jun 2011 11:23:57 +0200
Organization: Ada @ Home
Message-ID: <op.vxiu170mule2fv@douda-yannick>
References: 
 <8a5765ba-622a-42cd-9886-28ed7cfed31e@s17g2000yqs.googlegroups.com>
 <4dff5be5$0$6565$9b4e6d93@newsspool3.arcor-online.net>
NNTP-Posting-Host: HfNAdMB88ZE8crK0iV2fMQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: Quoted-Printable
X-Complaints-To: abuse@aioe.org
User-Agent: Opera Mail/11.11 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: g2news1.google.com comp.lang.ada:20010
Date: 2011-06-23T11:23:57+02:00
List-Id: <comp.lang.ada>

Le Mon, 20 Jun 2011 16:40:36 +0200, Georg Bauhaus  =

<rm.dash-bauhaus@futureapps.de> a =C3=A9crit:
> Not that it matters most, or is most important to the subject
> of understanding modularity and parallelism,  but I must mention
> that there remain a few major blind spots in FP circles, IMHO.
> It won't help as is.
>
>  "There is nothing more dreary than the corporate
>   bureaucracy of OOP, and few things more lovely
>   than the mathematical elegance of FP."
>
> Yes, I'd agree that O-O bureaucracy and spaghetti code can be
> correlated.  Why, however, do we not seem to see bureaucracy in ML
> source text?
>
> 0. There is less ML text.  Different problem domains, too.
> Perhaps suggesting a different kind of program right from the start.
>
> 1. Actually, they use imperative style or suitable contortions
> in functional programming when efficiency is required.  I remember
> looking at the chapter on Fusions in Bird's FP in Haskell
> book. The chapter's subject is messy, the approach produces
> text similar to the lengthier noodles in Wirth's algorithms book,
> conflating things for efficiency reasons.  Where is the mathematical
> elegance in that?
My small-talk: this is simply failing with the simple rule which is =E2=80=
=9Cuse  =

the best language for what it is best suited=E2=80=9D. Troubles comes wh=
en you  =

want only one for everything.

-- =

=E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D  [Ep=
igrams on  =

Programming =E2=80=94 Alan J. =E2=80=94 P. Yale University]
=E2=80=9CStructured Programming supports the law of the excluded muddle.=
=E2=80=9D [Idem]
Java: Write once, Never revisit