Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

You can do this already. But it doesn't make sense to do this instead of creating accessors.

IMHO, accessors are way too heavy instrument. The same objection as using regex for trimming whitespace applies: sending tank division to capture unarmed village.

Also enforcing/encouraging OO programming style where it is not appropriate is bad, unless you are a book author ;-) Anything connected with classes and instances of them requires the problem that fits this model (remember Simula-67 in which the concept was originated stems from simulation language Simula, where this is lingua franka: simulation objects typically exist in many-many instances ). It is not a universal paradigm, as some try to present it.

This topic is actually a part of BioPerl vs BioPython debate and I think one of the reasons that Perl so far holds its own for small bioinformatic programs (say less then 1K LOC) written by researchers is that it introduces less overhead and programs written in it consume less memory while processing the same data sets (which is important for server nodes with only 128GB of RAM, which are most common for bioinformatic clusters nows -- only few "large memory nodes" have 1TB or more of RAM ). See, for example:

https://digitalcommons.unomaha.edu/srcaf/2013/schedule/106/
Previous work here at UNO1 has documented that BioPerl remains the most popular bioinformatics language. Looking to expand on this, we wished to evaluate the responsiveness of BioPerl to the needs of its community. To accomplish this, we identified major revisions in the source code and then set about data mining the official mailing list. This mailing list serves as the principal interface for communication about BioPerl.
https://link.springer.com/article/10.1186/1471-2105-9-82/figures/3
Speed comparison of the BLAST parsing program. Speed comparison of the BLAST parsing program implemented in C, C++, C#, Java, Perl and Python. The programs were run on Linux and Windows platforms. The input file was a 9.8 Gb file from a BLASTP run.
Perl versus Python
Perl clearly outperformed Python for I/O operations. Perl was three times as fast as Python when reading a FASTA file and needed half of the space to store the sequences in memory (Fig 4). From the results of the global alignment and NJ programs Python appeared to have better character string manipulation capabilities than Perl. Even though the NJ program required reading a file, where Python did not perform well compared to Perl (Fig 2), the computation of the dissimilarity matrix was actually the most discriminating task, since more than 90% of processing time was taken up by this step for every language except C, where it took up 75% of processing time.
Python was the worst performer for parsing a BLAST file (Fig 3), taking more than 38 minutes to process the file compared to Perl, which took only 7.28 minutes. This difference did not arise from any inability of Python to handle large files, since it took only 3.2 minutes to read the file without processing the lines. Perl accomplished the same task in only 1.4 minutes.
Perl emphasizes support for common application-oriented tasks, by having built-in regular expressions, file scanning and report generating features. Python emphasizes support for common programming methodologies such as data structure design and object-oriented programming.
https://www.koreascience.or.kr/article/JAKO200922951807583.pdf
In an evaluation of individual languages, Java shows the best overall performance in most tasks in terms of both execution time and memory management BioJava effectively takes advantage of its native language, Java, unlike BioPython. Interestingly, Perl and BioPerl outperformed Java and BioJava when processing small data sets. In addition, Perl is very powerful for string manipulation, even compared to both Java and Python. According to the experimental results, the string manipulation operation in Python seems to be inefficient compared to Perl and Java, the inefficiency is also shown in the experiment by Fourment and Gillings based on the BLAST parsing program 13 On the other hand. Python seems to be better in memory management than Perl.
Compared to other languages used in this experiment, BioPython performed very poorly for most tasks. BioPython was much slower and consumed more memory in all tasks than any other language used in this experiment. This result is surprising to us and indicates that BioPython may need a significant improvement in language implementation

Comment on Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

Replies are listed 'Best First'.
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by ikegami (Patriarch) on Sep 18, 2020 at 09:17 UTC
Also enforcing/encouraging OO programming style where it is not appropriate is bad Do you listen to yourself? Having modules provide functions is not bad. Besides, I said you can already do this without accessors.	[reply]
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by Anonymous Monk on Sep 18, 2020 at 01:14 UTC
https://link.springer.com/article/10.1186/1471-2105-9-82/figures/3 Oh hey, I've seen that link before. You're ignoring the elephant in the room: if you want speed, you need to use C. Oh, and C++ isn't very far behind so maybe it's worth using that instead because std::string is so much nicer than cstrings. I'm not sure what you're up to here, I see no point to any of your recommendations on Perl 7 and, worse yet, you insist on misquoting Knuth to support your position. Ok, I'm sorry. That probably feels like an attack. I'd like to think your heart is in the right place and that you're really trying to make Perl better. Assuming your realm is genetics, the way to make Perl faster is XS so you can use C for the speed. Micro-optimizing on $_ is not the answer.	[reply]


Think about Loose Coupling
	PerlMonks