[seqfan] Re: Programming languages

[Fred Lunnon]

<< Premature optimization is the root of all evil. >>

  Perhaps mildly exaggerated ... but excellent advice, nonetheless.
And incidentally, not unrelated to a more general principle, enunciated by
R. A. (Tony) Brooker (and doubtless many engineers in many disciplines:
    " If it works, for God's sake don't change it! "

  I (mis-)spent a large part of my youth hand-coding combinatorial problems
--- including various polyomino sequences --- in assembly language for
early
and now long-deceased computers.I learnt much about software implementation
that way, but it was an expensive education.

  Probably any relatively inexperienced programmer initially approaches
such
challenges from the same direction: sitting down to write the most
efficient
program possible, before executing it as much as practicable.  But in the
long
term, there's so much totally arse-forwards about such a naïve strategy
that it
is hard to know where to start (or stop) the critique.

  It largely boils down to determining what exactly are you really want to
achieve:
more specifically: what criterion of "efficiency" should you attempt to
optimise?
  Speed of execution?  For square polyominoes, run-time is an exponential
function of the tile count, so  just one more output will cost 4x as long
period.
  Memory usage?  Most speed-up eventually starts to involve caching data in
tables and running into data size limitations.
  Programming effort?  For the wet-ware effort devoted to writing one big
fast
program, you might write  k  short small programs for different problems,
running
them in parallel on separate hardware cores, multiplying your productivity
 k-fold.

  There are also theoretical obstructions.  From computability studies it
emerges
that there exist problems for which _no_ fastest algorithm exists: and this
feature
 trickles down even into elementary combinatorial problems.  And you have
already
found, you can bust a gut to implement some involved algorithmic
"improvement",
only to discover that it results in no practical increase in speed (or even
a decrease).

  Finally repetitive wet-ware effort devoted to similar individual problems
might
ultimately have instead been devoted to a more general algorithm, designed
to input a tile specification, rather than simply a number of tiles.  For
example,
have you considered the following, or a similar approach?
Aaron Siegel - Polyformer
https://www.youtube.com/watch?v=8NA4Y5S5dt0

  Of course, if you spend long enough deciding on the optimal strategy,
there is always the risk that you never actually get anything else done at
all ...

WFL



On Wed, Sep 20, 2023 at 1:22 PM <hv at crypt.org> wrote:

> John Mason <masonmilan33 at gmail.com> wrote:
> [...]
> :With objects: 24 seconds
> :Without: 24 seconds
> :So apparently my fears were unjustified.
> :Does anyone have a similar experience?
> :Does anyone want to tell me I'm using the wrong programming language
> anyway?
>
> Premature optimization is the root of all evil. :)
>
> Generally, I'd expect to write the fastest code in the language(s) I'm
> most familiar with.
>
> In most cases, however, I start off not knowing much about a problem I'm
> investigating: at that stage speed and flexibility of development are more
> important than speed of execution.
>
> As such I tend in almost all cases to start off exploring and prototyping
> in Perl (which I know very well), and rewrite in C (which I know pretty
> well) only when I'm fairly confident that a) I won't get execution time
> down to something reasonable just with Perl, and b) I know what algorithms
> and data structures I'm going to need in C.
>
> Of particular value is a good profiler: for Perl we are blessed with an
> especially good one, Devel::NYTProf [1]. I'm not aware of anything
> remotely as powerful for Java (or for C/C++).
>
> Hope this helps,
>
> Hugo van der Sanden
>
> [1] https://github.com/timbunce/devel-nytprof
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>