Talk:Bernstein basis polynomials

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.

But "Subprogram(1)" is a meaningless abstraction (admittedly a pet hate of mine), the complete antithesis of 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.

Apart from a few words in bold, and arguably better whitespace/linebreaks in the real entry, that half of the task description is identical.

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?

I would level the same criticism against the great DK, and be five times as vociferous had he used "Algorithm M1".."Algorithm M5".

I don't actually know the text you refer to very well, but given the chance I might have said: at least call it "Algorithm LM".

Further, there is a tiny hint M might stand for multiplication, but there is nothing at all in "Subprogram(1)".

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?

I would not/did not say silly, but I would stress meaningless.

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?

Comparing clearly and intuitively defined things is much easier than comparing vague/abstract things.

In which case providing obvious back-references is a boon, is it not?

NOT. Should the code ever be used in a real program, what gain does needing a backlink to an rc page to understand it gain?

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)

You appear to have invented a criticism there I did not make. --Petelomax (talk) 01:40, 28 May 2023 (UTC)

Thanks for your input. We seem to belong to entirely different schools of programming. --Chemoelectric (talk) 10:59, 28 May 2023 (UTC)

No worries, I made my case, it didn't stick, I'll not dwell on it. --Petelomax (talk) 08:07, 29 May 2023 (UTC)

I should like to make a comment on which I use the term "subprogram" when giving numbers to parts of the code to be written. It is simply that I can think of no programming language that uses that term in its syntax. We have "subroutine", "procedure", "function", "predicate", ... even "word" (that goes in a "dictionary"). But not "subprogram". "Subroutine" and "procedure" would be appropriate terms, but Fortran made it seem a "function" is not also a "subroutine", when the difference is merely syntactic. And what is a "function" and what a "procedure"? What Common Lisp calls a "function", Scheme calls a "procedure". Some other languages distinguish "function" from "procedure", while others call a "function" a "procedure". But "subprogram", although a dated term, does not have these problems.

(Just to be crystal clear, it is much more the "(1)" than "subprogram" I objected to --Petelomax (talk) 08:07, 29 May 2023 (UTC))

As for what name one actually uses for a subprogram, does this not depend more on the traditions of a particular language than it does on the task at hand? One calls a predicate "whateverp" or "whatever-p" in Common Lisp, but "whatever?" in Scheme, even though both languages allow punctuation symbols in names. In other languages one writes "is_whatever", and in others "isWhatever" or "IsWhatever". In traditional Fortran (the language of LAPACK), one completely avoids names over six characters long, so it might be "WTEVER". (This is why LAPACK subroutine names are the way they are.) In my own examples here, I used entirely unlike names in different languages. (I have added ATS, Object Icon, and m4 since the initial two, which already had entirely different names for the parts.) We all have opinions on these things. I for one, dislike camel-case, and am annoyed if I can't use "| y = p(x)² |" as a variable name, as one can in Common Lisp or Scheme. --Chemoelectric (talk) 11:23, 28 May 2023 (UTC)