Re: project euler 26

[Ben Bacarisse <ben.usenet@bsb.me.uk>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2023-09-04 18:01, Ben Bacarisse wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On 2023-09-04 13:06, Niklas Holsti wrote:
>>>> On 2023-09-04 12:19, CSYH (QAQ) wrote:
>>>>> I am new to Ada, I know is there a good way to start this program?
>>>>> thanks
>>>>> https://projecteuler.net/problem=26
>>>> First invent/discover the method (algorithm) for solving the problem,
>>>> without thinking about the programming language.
>>>> I don't think any language has built-in features that would lead to a
>>>> direct solution, although some functional language with lazy evaluation
>>>> could come close, because such languages can manipulate unbounded
>>>> (potentially infinite) sequences of values. Such sequences can be handled
>>>> in Ada, too, but with more effort -- they are not "built in" to Ada.
>>>
>>> Infinite division does not require big numbers, which Ada 22 has, but I
>>> wound not use them anyway because the performance would be abysmal.
>>>
>>> BTW, Ada is perfect for numeric algorithms no need to resort to functional
>>> mess... (:-))
>> Perfect?  That's a bold claim!
>
> Ada is a very improved descendant of Algol 60, which was designed to codify
> algorithms.

Yes, though I was respond to you narrower remark about being perfect for
numeric algorithms.  Are you expending that to perfect for every kind of
algorithm?

>> Mind you, I don't think this problem is really a numerical one in that
>> sense.  It needs some simple integer arithmetic but then every language
>> is perfect for that sort of arithmetic.
>
> That is still all about algorithms

Yes but, again, that's not what I was responding to.

> (rather than about for example building
> abstractions as in the case of OOP)

That's interesting.  You don't consider using functions and procedures
(possibly higher-order ones) to be a way to build abstractions?

>> Using a functional mess (Haskell) a simple, native solution (i.e. using
>> no modules) is only 9 lines long.
>
> Apart from the fundamental inconsistency of functional paradigm: computing
> is about transition of states and nothing else; the imperative languages
> express solutions, i.e. an algorithm. Functional, and in general,
> declarative languages express puzzles.

Rather than try to unpick that paragraph I'll just say that they can,
none the less, give simple solutions to this sort of programming
problem.

-- 
Ben.