[seqfan] Re: Programming languages

[Allan Wechsler]

I do a lot of programming in Java for my work.

If you are concerned about creating a lot of objects that are used only
temporarily, and then dropped, you are probably underestimating Java's
garbage collector. Java is actually very good at cleaning up transient
objects. We've been surprised several times, on occasions where we wrote
some code the simple, easy-to-understand way, expecting that we would have
to go back through it once it was working, and cut back on gratuitous
object creation -- only to find that there was no increased load at all,
that the Java compiler had figured out that the objects were transient, and
that they were getting recycled immediately after use.

On Wed, Sep 20, 2023 at 1:33 PM John Mason <masonmilan33 at gmail.com> wrote:

> 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/
> >
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>