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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,b3f07bd1ad77d438
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!goblin2!goblin1!goblin.stu.neva.ru!eternal-september.org!.POSTED!not-for-mail
From: Warren <ve3wwg@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: The state of functional programming
Date: Thu, 29 Jul 2010 15:20:48 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <Xns9DC47362DB91WarrensBlatherings@85.214.73.210>
References: 
 <2adc4d8d-210e-429c-8188-9b1e99c2718e@d17g2000yqb.googlegroups.com>
 <g24nvegdi17t$.1azxwn1rwjixi$.dlg@40tude.net>
 <Xns9DC39A29C4AD7WarrensBlatherings@85.214.73.210>
 <1oubrlamjqe8q$.bdwkb9i7ys6b$.dlg@40tude.net>
Injection-Date: Thu, 29 Jul 2010 15:20:48 +0000 (UTC)
Injection-Info: mx03.eternal-september.org;
 posting-host="9f8M0iN5t54V+4DF/iqO8g";
	logging-data="16736"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18ZUHLiGBw66I1nrc40zKf5okx/0cL+PIA="
User-Agent: Xnews/5.04.25
X-Face: 
 &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j
Cancel-Lock: sha1:Zhm2dAzrHV5Rp6Grp3j9XkpSeXQ=
Xref: g2news1.google.com comp.lang.ada:12668
Date: 2010-07-29T15:20:48+00:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov expounded in
news:1oubrlamjqe8q$.bdwkb9i7ys6b$.dlg@40tude.net: 

> On Wed, 28 Jul 2010 19:09:17 +0000 (UTC), Warren wrote:
> 
>> Each collection of languages best solve problems in their 
>> domain of applicability.
> 
> That reminds me someone's saying about 5GL in early 90's: "if 5GL is
> an answer what was the question?"
> 
> What are the domains of poor languages? Since they must exist, 

Perl ;-)

>> For my money, FP still is less generally effective because
>> it relies on special tricks/algorithms to narrow down the
>> huge number of paths for a solution.
> 
> This universally applies to all declarative languages.

I think you missed my point - perhaps it wasn't expressed
clearly.

As I understand it, a FP tries to determine conclusions 
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results 
obtained.

However for more "practical" sized problems (we could argue
what "practical" sized problems are), the number of "things"
that must be analyzed becomes huge - taking 'forever' to 
solve. To counter this, existing FP technologies use 
special tricks for reducing the number of "things" to be 
considered. 

The problem with this approach is that some problems 
then won't lead to a solution because some of the paths 
that may have lead to a solution were eliminated. Another
side effect of this is that it may lead to suboptimal
conclusions (the better possibilities were eliminated).

The "problem set size" issue, as I understand it, is still
the main area of intense research in FP. But as it sits
presently, the issue is still essentially unsolved. 

Some big improvements (special algorithms) have been 
developed over the years to make FP more practical, 
but in essence that same basic problem still exists.

Warren