Talk:Function (computer programming)

message: "however, the C programming language and its programmers view subroutines simply as functions that do not return a value."
The one thing in life that frustrates me most is arguing over definitions, so this is just a thought. I'm a (mostly) self-taught C programmer, so I have very little use for terminology, but what about functions that return only success or failure... Would they not be considered a sub routine?
--The Extremist
: Returning a boolean is still returning a value. IMHO. --Mike Van Emmerik 03:51, 12 May 2005 (UTC)
thread_title: New stuff

message: Aren't subroutines and methods pretty simliar? If so, I think each article should mention the other one to some degree. -Hyad 2 July 2005 23:26 (UTC) 
I actually think that merging the article 'Function Stack' with 'Subroutine' is a good idea. I also think that the page describing a 'Subprogram' should be reintroduced. --Anonymous 16:20, 15 July 2005 (UTC)
thread_title:  Subroutines and Methods 

message: I think that the Parameter (computer science) article ought to be dropped and redirected to this article.  Please see the comment on Talk:Parameter (computer science).
—Preceding unsigned comment added by Donhalcon (talk • contribs) 07:14, 23 October 2005
What? No. Parameters are vaster then simple methods, although the article doesn't seem to explain that. Look, if you have an equation the parameters of that equation are what go in to fill (ex) x, y, and z. The Parameter artile needs a re-work, but it should not be incorporated into a single article
Furthermore, the separation of facts is nessicary for a working encyclopedia. You wouldn't combind Time with Watch just because of the similarities. Or god with devil because they exist within the same idea. The more separated objects are the better.
http://www.answers.com/parameter&r=67
A parameter is something that is passed to the subroutine. They are separate concepts. Poppafuze 06:04, 28 September 2006 (UTC)
thread_title:  Subroutines and parameters 

message: Currently, the Subroutine section in Control flow and the Subroutine article are both covering the same topic. When a section summarises the content of a linked article, it should be a short summary and should not include any significant content that is not in the linked article - this is not currently the case at all. The section in Control flow on subroutines is not short, it is not a summary, and it contains content that is not in the main article. Any objections to this proposed merge?—greenrd 13:20, 27 May 2007 (UTC)
replies: text: I am surprised to hear a claim that these articles are covering the same subject.  If they read as if they are covering the same subject then some rewriting is needed.  I have read them and don't think they read as if they are covering the same subject. Derek farn 15:01, 27 May 2007 (UTC)
replies: text: Perhaps I was not sufficiently clear. I am talking about the Subroutine section in the Control flow article, not the entire Control flow article. Both that section and the Subroutine article are talking about the same subject, subroutines...—greenrd 16:47, 27 May 2007 (UTC)

text: You were sufficiently clear, but I was insufficiently switched on.  Good call.  Do the merge. Derek farn 19:24, 27 May 2007 (UTC)
thread_title:  Proposal to merge section from Control Flow article into Subroutine article 

message: in an entry on computer science? wtf?  12.108.188.134 (talk) 19:26, 1 December 2009 (UTC)
thread_title: [[Subroutine#Conventions|flagrant use]] of [[Wikipedia:Avoid_weasel_words|weasel words]]

message: This subroutine history is far better on the early history of subroutines. The idea of subroutines was there pretty much from the beginning and both Turing and Zuse provided special hardware to support them. Arguably Ada invented the concept. I also believe much of the text here could be moved to the Self-modifying code and Call stack articles instead and this article made a bit more high level. Dmcq (talk) 14:54, 6 December 2009 (UTC)
thread_title:  History needs updating + too low level 

message: No discussion of "function" is complete with mention of preconditions and postconditions.  — Preceding unsigned comment added by 74.85.3.146 (talk) 03:40, 2 June 2011 (UTC)
thread_title:  NO mention of pre and post conditions 

message: this page wasnt helpful, i made this edit -- http://en.wikipedia.org/w/index.php?title=Subroutine&curid=32177451&diff=516519142&oldid=510553280  — Preceding unsigned comment added by Coginsys (talk • contribs) 10:39, 8 October 2012 (UTC)
replies: text: Your change was reverted (twice) because it wasn't as clear and meaningful as the version that was there before. - David Biddulph (talk) 13:02, 8 October 2012 (UTC)
thread_title:  this page wasnt helpful, i made this edit -- http://en.wikipedia.org/w/index.php?title=Subroutine&curid=32177451&diff=516519142&oldid=510553280 

message: I was going to add something about call by name and found there's no general discussion of argument passing, only specific language instances.  Looking at this talk page I read 
I agree that the article needs some work. Peter Flass (talk) 13:44, 14 January 2013 (UTC)
replies: text: I added a table on argument-passing conventions.  I didn't cite a source because I found so many and synthesized this using several of them. Peter Flass (talk) 13:45, 15 January 2013 (UTC)
thread_title:  Calling conventions 

message: Subroutine could become a redirect. Function is a broader term. Python does not have subroutines. Functions that do not specify a return value return None (python's null value)Panpog1 (talk) 00:49, 7 May 2013 (UTC)
replies: text: Function is not a broader term than subroutine; in fact in many contexts it would be considered narrower.  A subroutine may or may not be defined to return a value.  If it does not return a value, it is not a function.  In interpretive languages like Python, all subprograms are functions and have some convention for cases which do not return explicit values, substituting a value like "None" or 0 or "Undefined".  In those contexts, these are functions whose result range includes that value.  But in most compiled languages, non-value-returning subroutines simply have no location designated for returning a value.  If there is to be only one article, it should be Subroutine as that does best at capturing the computational ideas involved; the term function tends to evoke the mathematical concept, which is related but misleading. --R. S. Shaw (talk) 06:23, 10 May 2013 (UTC)
replies: text: I agree with  a function is not a broader term than procedure call. In a formal sense a true function is not just a procedure that returns a value. It's a procedure that does not modify any external variables. Even many of the functions in Lisp aren't truly functions in the formal mathematical sense. But the more important issue is that procedure call is more general than function is. I also think the intro text to this article is wrong and should be changed. It describes "function" and "procedure call" as if they are synonyms when as we just described they are not. --MadScientistX11 (talk) 15:41, 10 December 2014 (UTC)
replies: text:  I suppose by "formal sense of a true function", you mean a mathematical function, and that is a different concept, thus OP use the term "function (computer programming)" to distinguish with that. In modern popular languages the word function is interchangeable with subroutine, it can have side effects, modify states, and be void valued. Since "function" is a more popular term than "subroutine", it is more appropriate to called this article function(computer programing).Golopotw (talk) 10:45, 3 November 2020 (UTC)

text: I'm not convinced it should be a separate article, but certainly the gist of this discusion should be in the subroutine article. Peter Flass (talk) 18:59, 10 December 2014 (UTC)
replies: text: Yes, it's always easier to kvetch and kibitz then to actually edit and fix ;-)  I agree. There isn't enough good content here to even consider branching off a new article and it would be good to clarify the actual distinction between functions, procedures, etc. If no one else does it I'll take a shot at it although I'm working on some other things right now but I'll keep this on the stack but if someone else wants to take it please feel free. --MadScientistX11 (talk) 19:29, 10 December 2014 (UTC)
thread_title:  Proposal for new article: function(computer programing) 

message: Subroutine#History has an incorrect chronology. The text claims 
The IBM 1620 does not have a hardware stack of registers for return addresses; it has a single register, IR-2.
The IBM 1130 was introduced in 1965, not before the mid-1960s. 
It is likely that some of the machines I mention below are themselves not the first.
The PDP-6 had the PUSHJ instruction well before the PDP-11, and the Burroughs B5000 had stack linkage before DEC.
The IBM 704 had the TSX instruction in 1954.
The UNIVAC 1103A had a return jump in 1956; unlike later architectures, the return jump on the 1103A specified where to store the return address independently from the address of the subroutine. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:49, 4 July 2021 (UTC)
thread_title:  Incorrect chronology 

message: I added stubs for procedures and functions. The article computer program has a wikilink to functions. Timhowardriley (talk) 18:03, 29 October 2021 (UTC)
thread_title:  Added ''procedures'' and ''functions'' stubs 

message: If that is intentional it should be pointed out in the text, but as of writing this, it only says "The following program prints "Hello world!" followed by "Wikipedia" on the next line.
def simple_function():
    print('Hello world!')
    print('Wikipedia')
simple_function()
# output will be:
Hello World!
Wikipedia
                  
def func(name)
    print("welcome "+name)
print(func("martin"))
#output will be: welcome martin
If you were to try and run this with Python, lines 6 and 7 would lead to syntax errors because they are not commented. The second example function is worse, the def statement does not end with a colon leading to another syntax error and because the function does not return anything, printing the return value of the function will print "None" after printing "welcome martin" 2001:7C0:2049:1D4:D511:6438:FDB6:39FC (talk) 14:33, 22 November 2023 (UTC)
thread_title:  The Python examples is riddled with mistakes 

message: This page has ALOT of history  is old with lots of edits. One could write an article about the history of this article :) I am new to this article, but have been programming for 30 years. I'm interested in improving this article  mostly for up and coming programmers wanting to learn the trade. As it was when I started working on it a few says ago, it was a mess  filled with inconsistent use of terms and wrong/bad info.
It tries to cover alot of ground  probably too much. But I'm focused on correcting what's there more than removing what's too far afield. At some point, maybe I'll get to refactoring into other pages.
Probably the biggest challenge for this article is scope. What is this about? Its title is 'function', but clearly it's also about subprogram ... and procedure ... and method ... OMG. Thing is, these terms all have meaning in the context of certain languages and environments. Even within particular contents, the meaning has changed over time -- over the last 70 years ... in arguably the most dynamic industry in human evolution! This article takes on a broad and deep topic.
But, I think it's worthwhile. Since whatever this article is about is clearly important.
But, to be useful and understandable, the article needs to be focused  as much as possible for such a board topic.
IMO this article always has been and should continue to be about the technology (or concept or construct) that is common among all languages and environments that allows programmers to structure code into chucks that can be used within a program to decompose a problem into a solution. 
One challenge of this is that there is no one, good word for that!
Seems that function has connotations of the technology in general, but it is also bound tightly to particular implementations  contexts such as particular languages. Using it for the name of the technology seems off the mark.
Some say that subprogram is the general concept. In fact, I think this article used to be called subprogram. Why was it changed? Was the change a mistake?
An issue that I personally struggle with is that I often confuse subprogram and subroutine even though they are quite different, right? Subroutine is like function  an implementation of subprogram, right?
The article does use the term callable unit which does seem to cover the desired focus of this article. Unfortunately, it's not commonly used  not nearly as commonly used as the other terms (function, subprogram, ...). But, a Google search does have hits (other than this article). So, it is a thing apparently.
I think this article should be renamed  either back to subprogram or to callable unit. And, content should be updated to use the new name throughout when referring to the general concept. And, to continue to use the more specific terms as context warrants. 
This article already has re-directs for all of the more specific terms and that should remain. Folks do and should continue to come to this article for all the various terms (callable unit, function, subprogram, ...).
...Just reviewed the edit history of this page. Seems that the page rename from subprogram to current function was done by Uni3993 in late 2022. And they seem to be permanently blocked :o) From that I take it that they have a history of over zealous modifications. It seems they did a global search and replace of 'subprogram' with 'function'. Well intentioned, but badly implemented. For one, when the word started a sentence, it was no longer capitalized. For another, I guess the result had "function and function". OMG. What a mess. Guy Harris fixed the many, many issues. Thanks for that!! I do want move away from 'function' as the general term, but do _not_ propose a simple minded search and replace. Would require a surgical approach.
 Stevebroshar (talk) 16:06, 4 February 2024 (UTC)
replies: text: Regarding : Wonderful! Employ some secondary research to find reliable sources about functions and dive right in. Timhowardriley (talk) 22:51, 5 February 2024 (UTC)
thread_title:  Article scoping; rename proposal 

message: In languages such as Algol 60 and PL/I, it is possible to define a procedure within another procedure. The procedure name identifies not only an entry point but also a context (stack frame) for local variables of the enclosing block. Similarly, in object oriented languages, an instance method is assciated with the context of an object, not just with its class. This is a special case of a Closure. I'm not quite sure where this belongs, but I believe that the article should discuss it in an NPOV manner and then give examples. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:43, 8 February 2024 (UTC)
replies: text: I don't think this article should attempt to describe every feature of a function in every language. I like that it tries to cover many aspects of functions (of whatever we call them) with examples from various languages. But, if we try to cover every feature for every language, the article will be too long ... and boring :) If it's wrong about algol and pl/l we should fix it. But IMHO we don't need to be exhaustive about each language. Stevebroshar (talk) 00:23, 13 February 2024 (UTC)
thread_title:  Procedure context