Re: Haskell, anyone?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 17 Nov 2015 09:10:14 +0000, Mark Carroll wrote:

> On 17 Nov 2015, Dmitry A. Kazakov wrote:
> 
>> On Mon, 16 Nov 2015 15:23:16 -0800, Paul Rubin wrote:
>>
>> Because declarative programming is non-algorithmic and no programming at
>> all, if taken seriously. It is like the idea of stateless programming, just
>> a fiction.
> 
> I do generally find it
> possible to translate algorithms from books like CLR(S) -- longest
> common subsequence or directed graph maximum flow or whatever -- to
> being purely declarative, it just means that I have to step back and
> really understand the idea and approach of the algorithm, rather than
> just mechanically translating their for loops and arrays and whatever
> into the appropriate syntax.

I don't think that is declarative. Imperative means that you have some
computational model and express the solution in terms of basic operations
of that model. Whether that be loops or recursive functions is not much
matter, except that former are much easier to understand, test, validate,
prove correctness, estimate numerical complexity, optimize etc.

A declarative approach is inherently non-constructive. You don't try to
understand anything, you just state something and let the inference system
to deduce the solution without understanding how it works. Without even
knowing what must be stated. Reverse problems are much harder than direct
ones, as we know from mathematics. That is why FP is so much try and error
rather than focused design. This a consequence of being declarative. Same
problems have other declarative approaches, e.g. relational algebra,
modeling languages etc.

Once you try to see what is going behind the scenes, it is no more
declarative.

"Let there be light" is declarative. Physics of electromagnetic fields is
imperative.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de