Anonymous user
Talk:Parsing/RPN calculator algorithm: Difference between revisions
Talk:Parsing/RPN calculator algorithm (view source)
Revision as of 04:45, 21 September 2016
, 7 years ago→Extraneous Requirements: Adding reply
(→Extraneous Requirements: Adding reply) |
|||
Line 18:
::: So... my current impression is that this might be a task labelling issue as much as anything else: if the task is about requiring some sort of logging or tracing of an algorithm, it should be named that (to allow the unadorned name to be used for implementations of the unadorned algorithm).
::: I should probably wait for others to weigh in on this? (Assuming they notice and/or care.) Maybe the right place to start, though, would be to pick one particularly egregious example page, and split it into two copies - one with the logging requirements and the other without? --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 17:26, 20 September 2016 (UTC)
:::: I'm obviously "making it up" in the sense that I am ''making'' a contribution by bringing ''up'' the problem and proposing possible solutions; but I'm not "making it up" as in fabricating the appearance of something out of nothing or falsifying in any way. I am simply trying to contribute to the development of this collaborative project by highlighting a problematic practice and exerting energy to help improve things. I didn't create the Village Pump page to give myself a false air of authority, or to trick anyone into thinking my proposal has undue weight; I created it so that I could clearly articulate my proposal and make it available for feedback, critique, addition, etc. If there is another procedure I should follow instead, please instruct me.
:::: I have no objection to the practice of soliciting and providing intermediate results. They can be very instructive. I have not suggested that we should limit or eliminate solutions that provide representations of intermediate stages. Nor do I think it is wrong to encourage and solicit such representations. I am only suggesting that ought not to constrain the kinds of solutions available for the core task by making such (interesting but extraneous) representations part of the required specifications.
:::: Now, as for the question of how we should free up these core tasks for a greater variety of approaches: I think that making the logging optional is more economical, more inclusive, and easier achieved than duplicating task pages. I think there are several good reasons for preferring the former:
::::# Making the logging optional only requires changing a single line.
::::# Making the logging optional opens the way for more idiomatic solutions in languages that are pure, type-safe, non-imperative, esoteric, etc., without invalidating any current solutions or generating a needless duplication of tasks that differ in just a slight detail.
::::# Making the logging optional encourages several different approaches to such tasks, which helps show how the kind of approach needed in one and the same language can vary greatly because of slight changes in the specification. (This is already how the [[Parsing/RPN_calculator_algorithm#Haskell]] answers have turned out here.)
::::# If the particular method of logging the intermediary stages of an algorithm are really very interesting (as they sometimes may be), then this logging should have it's own task (perhaps branching off of the core algorithm?). But most logging requirements are not interesting, they just require adding in a few print lines to the existing impure and imperative approaches. Establishing the precedent that any logging component should require the entire task to be duplicated seems like it could lead to lots of frivolous repetition, that would only make organization more difficult and search results longer.
:::: I am in no hurry to see this done, and would prefer taking the time to find the right approach rather than rushing ahead with a temporary fix that is not sufficiently robust. On the other hand, we could pick two different tasks and they each of these solutions, and see which seems to make more sense after the pages have grown another 6 or 12 months.
:::: I will be very interested to hear your feedback, and I am glad you are able to appreciate the rational and recognize the need for my proposal. I think a few subtle changes like this can really help open up space for an even wider variety of problem-solving approaches, and yet more illuminating and inspiring comparisons and contrasts between them.
:::: (Do you think we should migrate the bulk of this discussion to the Village Pump page, since it all about the general approach rather any particular implementation?)--[[User:Abathologist|Abathologist]] ([[User talk:Abathologist|talk]]) 04:44, 21 September 2016 (UTC)
| |||