Prev: team-ada (was e: Interfacing Ada with C
Next: ANN: GtkAda contributions v2.8
From: J.s on 28 Jul 2010 19:35
On Jul 28, 12:31 pm, "Jeffrey R. Carter"
<spam.jrcarter....(a)spam.acm.org> wrote:
> On 07/28/2010 08:24 AM, J.s wrote:
>
>
>
> > Does anyone have any thoughts on this?
>
> I think some relationship to Ada should be established when posting here.
>
> --
> Jeff Carter
> "The time has come to act, and act fast. I'm leaving."
> Blazing Saddles
> 36

Sorry, I wanted to get opinions from other ada programmers about the
usage of functional programming versus oop as well as the development
of other imperative languages. I see now my post was not appropriate
and certainly didn't mean to "troll".
From: Warren on 29 Jul 2010 11:20
Dmitry A. Kazakov expounded in
news:1oubrlamjqe8q$.bdwkb9i7ys6b$.dlg(a)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
From: Dmitry A. Kazakov on 29 Jul 2010 13:00
On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:1oubrlamjqe8q$.bdwkb9i7ys6b$.dlg(a)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.

And so does any declarative language. You declare some facts in whatever
form (as relations, as connections of blocks etc, for that matter, as types
in a strongly typed languages like Ada). The system infers from them some
executable code.

> 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.

Same with all others.

> 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).

Furthermore some declarative frameworks are weaker than TM. I.e. whatever
corpus of facts you take you would be unable to infer what you can using an
imperative language.

> 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.

I think that the main problem of all domain-specific languages is that, in
contrast to the acclaim, they aren't built around a domain. They are about
a class of some well studied methods. This class is them promoted as the
"domain."

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Warren on 29 Jul 2010 15:19
Dmitry A. Kazakov expounded in
news:a3iznu9uq49d$.1m9cupr81yhut$.dlg(a)40tude.net:

> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
...
>> 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.
>
> And so does any declarative language. You declare some facts in
> whatever form (as relations, as connections of blocks etc, for that
> matter, as types in a strongly typed languages like Ada). The system
> infers from them some executable code.

No, there is a big difference here.

In a non-FP language (Ada), you can solve _any_ problem so long
as you code it (you are coding the "how"). IOW, you have
solved the problem and specified it in code.

In FP, you define the "problem" (instead) and require from
it a solution. But FP cannot always solve that "problem".

A huge difference, that.

Warren
From: Dmitry A. Kazakov on 29 Jul 2010 16:40
On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:a3iznu9uq49d$.1m9cupr81yhut$.dlg(a)40tude.net:
>
>> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
> ..
>>> 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.
>>
>> And so does any declarative language. You declare some facts in
>> whatever form (as relations, as connections of blocks etc, for that
>> matter, as types in a strongly typed languages like Ada). The system
>> infers from them some executable code.
>
> No, there is a big difference here.
>
> In a non-FP language (Ada), you can solve _any_ problem so long
> as you code it (you are coding the "how").

Not quite. "How" need to be translated into the Ada code first. In some
cases it is not simple or even impossible.

> IOW, you have solved the problem and specified it in code.

No difference here. Any code is a language (Ada language, machine language,
the language of differential equations and so on). The FP code is as code
as Ada code is. The actual problem is that Ada code can be in most cases
effectively translated into machine code (and later into electrical
signals), while for FP code it is much more difficult. There are also other
problems related to maintainability. To be readable and maintainable the
code must be easily translated back into "how". I.e. the programmer must
understand what the code does. Arguably, FP code is farther removed from
programmer's "how" than Ada code.

> In FP, you define the "problem" (instead) and require from
> it a solution.

Rather you declare a solution. This is how declarative paradigm works.

(Don't forget that Ada has a declarative parts as well. You declare types
for example, and ask the compiler to solve "range 0..100".)

> But FP cannot always solve that "problem".

Same in Ada. Not every legal Ada program is compilable. I doubt that there
is a higher language where any legal program is compilable. The difference
is in relation, not in principle. Non-compilable Ada programs are less
interesting and numerous than their FP counterparts.

But my point was that this is characteristic for *all* declarative
languages. I think that no language can be 100% declarative. You can have
some well defined parts declarative, as in Ada, but making everything
declarative is like flying faster than light, or going beyond Turing
completeness, name it. Even if that were possible, we wound not be able to
understand what these programs do.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: team-ada (was e: Interfacing Ada with C
Next: ANN: GtkAda contributions v2.8