[seqfan] Re: Programming languages

Wed Sep 20 21:17:31 CEST 2023

Thanks Allan
That's just the confirmation I was looking for

On Wed, Sep 20, 2023 at 8:50 PM Allan Wechsler <acwacw at gmail.com> wrote:

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