[seqfan] Re: Programming languages

[John Mason]

Hi
Thanks for the replies.
1. Profiling. I have used profiling in a previous life, probably in C. I
will take a look at what Netbeans offers.
2.  "If it works, for God's sake don't change it". I've paid the price for
not adhering to that rule!
3. "Aaron Siegel - Polyformer". Interesting video, thanks.
4. COBOL. Been there. And Assembly Language too.

I would also be interested if anyone had an opinion on the specific problem
of programming Java with or without objects. I realise that a better
written program will save programming and debugging time. But if a job has
a foreseen runtime of 50 days, maybe some effort in increasing efficiency
will be worth it.

John

On Wed, Sep 20, 2023 at 7:02 PM SvenHSimon via SeqFan <seqfan at list.seqfan.eu>
wrote:

> Having some programming experience too I do not have much guidelines. I
> prefer to code with a strikt syntax and with some effort to minimize those
> small errors. It takes a lot of time to find errors in the code later, so
> efforts in advance pay out. Testing is important. On the long run  better
> programming is often throwing quicker hardware to unchanged software. So
> still there are Cobol programs - no one wants to pay the cost to change
> these old packages.
> Sven
>
> -----Ursprüngliche Nachricht-----
> Von: SeqFan <seqfan-bounces at list.seqfan.eu> Im Auftrag von Fred Lunnon
> Gesendet: Mittwoch, 20. September 2023 18:17
> An: Sequence Fanatics Discussion list <seqfan at list.seqfan.eu>
> Betreff: [seqfan] Re: Programming languages
>
> << 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/
> >
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>