Re: project euler 26

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

On 2023-09-11 18:13, Ben Bacarisse wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 2023-09-10 21:22, Ben Bacarisse wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> You should think about whether storing
>> represents an issue, e.g. in terms of performance and/or space. If it does
>> you should consider suitable implementation of storage that provides
>> required overall performance of needed operations, like insertion, search,
>> cleaning up etc.
> 
> Yes, in Ada.  Since I can't use universal algorithms, it pays to decide
> all this first because changes will be costly.

There are no universally applicable algorithms.

> But in some other
> languages I can try various schemes and measure or profile to see what
> time/space trade-offs there are between different designs.

So you can in Ada.

> This is
> easiest when I don't have to worry about all the changes that simply
> switching from, say, a list to an array will incur.

Measuring performance is not a simple task. Switching from the visitor 
pattern to loop is your least problem.

>>> But the conclusion seems to be that maximising over any container is
>>> just too simple to be worth making it a reusable component in Ada.  And
>>> even then it would not (as far as I can tell) work for native arrays.
>>
>> You do not need *any* container. You need a container, just one.
> 
> Yes, in Ada.  The cost of changing a design is going to be
> non-negligible, so we must make sure you get it right before too much
> code is written.

Right, because in that case you would have some non-trivial issue. So it 
would take much more efforts than merely calling a different function. 
There is an inherent difference between dealing with real size and 
complexity projects and hobby examples like this puzzle. The overhead 
you get from Ada pays off in programming en large. That was intentional 
language design.

>>> It would be a shame if something I said
>>> has ended up causing you to propose solutions you don't think are the
>>> best ones for this example.
>>
>> My understanding was that you wanted to see how to use the Ada standard
>> library containers with generics.
> 
> Well that's what it turned out to be.  At first I did not know that
> built-in types like arrays can't be covered in the same way.

I know no language where primitive built-in types may have classes. That 
is the major problem with type systems that they have first, second and 
third class citizens. Ada arrays (and fixed strings) are in a different 
basket than containers.

>> Generic programming in Ada (programming in terms of sets of types) is a
>> huge, almost infinite topic. One should be rather specific.
> 
> Sorry.  I was hoping that generalising from a range to an array or some
> other container would not be the huge topic it turned out to be.

Unfortunately it is, because nobody knows how to design a type system 
where proper arrays, that is one you could pass to a system library 
function written in C, can be dealt with in the same manner as a 
container in some polymorphic body. A mainstream choice is not to have 
proper arrays in the language at all. Then, logically, just forget that 
they exist in Ada. Problem solved!

>>>> In Ada you have freedom to choose your way, which also massively reduces
>>>> universality of any abstraction, which will never apply universally.
>>> That's a strange remark. You have to do things the Ada way. The
>>> freedom is only in choosing how to combine the specific tools in Ada's
>>> toolbox, and Ada also constrains how the tools can be combined.
>>
>> There are more than one way to skin a cat in Ada. You can choose one drawer
>> in the Ada toolbox and feel comfortable with what it provides all your
>> life.
>>
>> "Ada way" among Ada users rather refers to an approach to software
>> engineering in general. Like upfront specification, separation and careful
>> design of interfaces, modular design, problem space driven choice of types,
>> earliest possible error detection etc.
> 
> Yes, I remember the 80s!  It's rare to have specifications that don't
> change these days.

I remember a book on structured programming from 80's describing exactly 
the way programs are written today as an example how projects are doomed 
to fail. As I said, Dark Ages.

> And general remarks like "problem space driven
> choice of types" apply to all languages.

In most languages there is no choice because all scalar types are 
predefined.

> What matters is what types the
> language offers, and what the interfaces to those types are.

That does not matter at all. Matters the type algebra by which 
programmer can create types suitable to model the problem space entities.

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