Talk:Bernstein basis polynomials: Difference between revisions

From Rosetta Code
Content added Content deleted
Line 2: Line 2:
Some people (mainly idiots) say "naming is hard", but "Subprogram(1)" is utterly ludicrous, and should not appear in the task description, comments, or output.
Some people (mainly idiots) say "naming is hard", but "Subprogram(1)" is utterly ludicrous, and should not appear in the task description, comments, or output.
I would suggest rewording the task as "1. Write a function (named say tobern2) to transform" ... and further merge the steps 1/6, 2/7, ..5/10, in order that you can then just say "use this". I will also question whether anyone thinks having that "nicely printed ALGOL 60" really adds anything useful. --[[User:Petelomax|Petelomax]] ([[User talk:Petelomax|talk]]) 16:52, 27 May 2023 (UTC)
I would suggest rewording the task as "1. Write a function (named say tobern2) to transform" ... and further merge the steps 1/6, 2/7, ..5/10, in order that you can then just say "use this". I will also question whether anyone thinks having that "nicely printed ALGOL 60" really adds anything useful. --[[User:Petelomax|Petelomax]] ([[User talk:Petelomax|talk]]) 16:52, 27 May 2023 (UTC)

People may not understand why I did what I did. It is largely because what other people write is so often difficult to follow, even though they are trying really hard. They are too afraid to sound different from a novelist! There is actually no great reason for a programming task to be written "colloquially". It should be absolutely straightforward.

I used Algol 60 in lieu of making up my own pseudocode, the way others do. Algol 60 exists ''primarily'' for this purpose: it is an unambiguous language whose main use is for publishing algorithms in print. The "pretty-printing" is actually the ''standard'' form of the language. The "nicely printed Algol 60", which I used in lieu of ambiguous pseudocode, is actually the only ''true'' Algol 60 code on the page. I did the GNU MARST version merely to verify that I had written the Algol 60 correctly. It is in a compiler-specific entry syntax, that it would not share with a different implementation of the language.

Algol 60 is still well suited to the task of conveying algorithms, as long as the algorithm does not need records or such. If there is any doubt as to the meaning of what is written, a person can refer to the [https://www.masswerk.at/algol60/modified_report.htm ''Modified Report on the Algorithmic Language Algol 60''], and to the earlier [https://www.masswerk.at/algol60/report.htm ''Revised Report''].

As for "Subprogram (1)", "Subprogram (2)", etc., these are not the names of subroutines. They are reference numbers, akin to "Equation (1)", "Equation (2)", etc. If you think these are stupid "names", then what about Donald Knuth using "Algorithm M" for a long multiplication routine, etc., in his classic ''The Art of Computer Programming''? And I do not see that merging the parts of the task would serve any purpose except to make the writing sound less like technical writing, and to make it easier for a reader to accidentally skip one part of the task.

Regarding having the example codes refer back to the reference numbers in the task description: is there any reason ''not'' to do this, other than some might think it looks silly? What is the purpose of Rosetta Code? Is it to write code that looks really terrific, about which no other programmer will come along and say "That looks stupid!"? Or is it to mainly facilitate comparison between languages and how they represent the same algorithm? In which case providing obvious back-references is a boon, is it not? The code here is pedagogical and for the sake of recording things. It is not killer apps, and it also is not meant to please the boss.

As for why the Python code is full of descriptions of what I am doing, that is very simple to explain: the Python program is the first draft of the task itself! I composed the writing there. --[[User:Chemoelectric|Chemoelectric]] ([[User talk:Chemoelectric|talk]]) 00:39, 28 May 2023 (UTC)

Revision as of 00:40, 28 May 2023

Get rid of "Subprogram(1)".."Subprogram(5)"

Some people (mainly idiots) say "naming is hard", but "Subprogram(1)" is utterly ludicrous, and should not appear in the task description, comments, or output. I would suggest rewording the task as "1. Write a function (named say tobern2) to transform" ... and further merge the steps 1/6, 2/7, ..5/10, in order that you can then just say "use this". I will also question whether anyone thinks having that "nicely printed ALGOL 60" really adds anything useful. --Petelomax (talk) 16:52, 27 May 2023 (UTC)

People may not understand why I did what I did. It is largely because what other people write is so often difficult to follow, even though they are trying really hard. They are too afraid to sound different from a novelist! There is actually no great reason for a programming task to be written "colloquially". It should be absolutely straightforward.

I used Algol 60 in lieu of making up my own pseudocode, the way others do. Algol 60 exists primarily for this purpose: it is an unambiguous language whose main use is for publishing algorithms in print. The "pretty-printing" is actually the standard form of the language. The "nicely printed Algol 60", which I used in lieu of ambiguous pseudocode, is actually the only true Algol 60 code on the page. I did the GNU MARST version merely to verify that I had written the Algol 60 correctly. It is in a compiler-specific entry syntax, that it would not share with a different implementation of the language.

Algol 60 is still well suited to the task of conveying algorithms, as long as the algorithm does not need records or such. If there is any doubt as to the meaning of what is written, a person can refer to the Modified Report on the Algorithmic Language Algol 60, and to the earlier Revised Report.

As for "Subprogram (1)", "Subprogram (2)", etc., these are not the names of subroutines. They are reference numbers, akin to "Equation (1)", "Equation (2)", etc. If you think these are stupid "names", then what about Donald Knuth using "Algorithm M" for a long multiplication routine, etc., in his classic The Art of Computer Programming? And I do not see that merging the parts of the task would serve any purpose except to make the writing sound less like technical writing, and to make it easier for a reader to accidentally skip one part of the task.

Regarding having the example codes refer back to the reference numbers in the task description: is there any reason not to do this, other than some might think it looks silly? What is the purpose of Rosetta Code? Is it to write code that looks really terrific, about which no other programmer will come along and say "That looks stupid!"? Or is it to mainly facilitate comparison between languages and how they represent the same algorithm? In which case providing obvious back-references is a boon, is it not? The code here is pedagogical and for the sake of recording things. It is not killer apps, and it also is not meant to please the boss.

As for why the Python code is full of descriptions of what I am doing, that is very simple to explain: the Python program is the first draft of the task itself! I composed the writing there. --Chemoelectric (talk) 00:39, 28 May 2023 (UTC)