Talk:Subroutine/Archive 1

This is pretty underwhelming. An abstract method - one with, by definition, no implementation is a "subprogram". That is, to say the least, a novel interpretation. It would have been better to leave the articles separate and just refer to subprogram instead of making one big indigestible mass; if I quickly want to know what an abstract method is, it wastes my time to wade through a bunch of turgid and irrelevant prose about subprograms in general. I'll split it back apart at some point if nobody else does it first. Stan 01:01 24 May 2003 (UTC)

I guess you are right. Method stuffs seem beyond the scope of the article. -- Taku 01:23 24 May 2003 (UTC)

Jesus H. Christ, this article is an absolute dogs breakfast.

Can you tell me more constructive comment? We can work on to improve the article. -- Taku 01:49 24 May 2003 (UTC)

---

What literature in CS discusses "subprograms"? This terminology seems both antique and unobvious, in light of more useful and structurally clearer analyses in terms of functions. --FOo 03:45 24 May 2003 (UTC)

My old Sippl microcomputer dictionary from 1975 does define "subprogram", as a sort of "program segment", hee hee. But it's a rather archaic term, not the best choice for understanding; if you have to spend a paragraph at the beginning of the article defending the term, that's not a good sign. Stan 04:39 24 May 2003 (UTC)

You are maybe true. But then what should be better? Subroutine? It sounds to me a special subprogram in imperative programming language. -- Taku 14:12 24 May 2003 (UTC)

If subprogram is really the most general term albeit archaic -- that is, it includes subroutines, functions, coroutines, procedures, et al., but only because the literature at the time had not formally separated them -- then perhaps it might simply be discussed as an archaic term inclusive of these. However, I don't think that's the case -- the usual CS literature is in terms of functions and procedures, plus generalized representations of a computation task such as continuations.

Given the defensiveness of the term in the article (e.g. "Although uncommon, subprogram (meaning part of program) is a concise and precise term because other commonly used terms imply a philosophy about programs.") I think this is an idiosyncratic usage and not part of the mainstream literature. Wikipedia's reference to CS (or any other field) should be in the commonly-used terms that readers can expect to find in the literature -- not idiolects. --FOo 13:45 9 Jun 2003 (UTC)

Actually that is my old comment. Please read following below. -- Taku 21:25 9 Jun 2003 (UTC)

---

This page is becoming something of a monster. I really think two or three paragraphs would be quite long enough for a suitable encyclopedia definition of a subroutine/function/whatever. I'd also support a move to subroutine. Subprogram is nice word, but we are unfortunately limited by the words people actually use. We certainly don't need any information on how subroutines are implemented by compilers - this is way too deep for Wikipedia. -- Cadr

I think the trouble is that a subprogram is really a huge topic. Even though the article is too complex, too long, we haven't yet cover nested functions, exception handling, co-routines, syntaxes, stack over flow and so on. And actually I disagreee with elminating implementaion details. Wikipedia should not simply offer summaries. It is quite important to show how subprograms work or are implemented in practice. About naming of the article. I think I am clueless about it. To me whateverr term seems not good, so I leave the issue about naming to folks, go ahead what you think good to name. -- Taku 18:50 1 Jun 2003 (UTC)

Of course the article should give a quick overview of how functions are implemented by compilers (variables pushed onto a stack, etc.), but 99% of people reading the article won't want or need to know the details -- especially not the details for a particular processor/platform. If you really want to have this information on Wikipedia, why not put it on a separate "Implementation of subroutines" page, or something like that? Remember that someone with only a basic knowledge of computers/programming should be able to get the gist of the whole article. -- Cadr

You do have a good point. I agree that the article went too far. But the trouble is that each feature of subprograms is often well tied to implementation. I really think that the section calling sequence or call by reference, call by name stuff should be too much detail for the readers. About the name, are people waiting for me to rename? -- Taku 14:28 10 Jun 2003 (UTC)

---

Major rewriting

First, great work P3do. Certainly revised version is more clear, simpler and easier to read. I was wondering is there any reason behind that you eliminated discussion about side-effect or actual and formal parameters? -- Taku 17:32, 20 Sep 2003 (UTC)

I'm glad you feel that way since you put most of the work into the old text. Actual vs. Formal parameters probably should be discussed; I didn't remove it intentionally. Perhaps you can add something? Also, I'm not sure just what you want to say about side-effects, but go ahead and add it. The worst that can happen is that someone will change it.  :-) -- Doradus 04:13, 21 Sep 2003 (UTC)

---

I added some notes on guidelines from structured programming, and I would value your comments TeunSpaans 20:35, 27 Sep 2003 (UTC)

Not sure I like it much. This is not a programming text: we're not teaching people how to program; we're describing the current state of knowledge in the field. Anyway, even if appropriate, the guidelines you describe are not "structured programming", which was defined very specifically by Dijkstra, and refers to the decomposition of programs into "structures" that have one entry and one exit. That other stuff you describe is perhaps a small part of extreme programming or something. -- Doradus 01:52, 2 Oct 2003 (UTC)

I reworked somehow. I think it is not so bad idea to discuss some practical examples or conventions now that the article is rather little too abstract and theoritical. -- Taku

Oh, it is a frustrating task to edit an article that Taku has set his sights on. I took some pains a while back to clean this article up, and now a dozen Taku-edits has left it almost as disarrayed as it was before I started. It does not look at all like an encyclopedia article any more, but a collection of random thoughts tangentially related to the general topic of subprograms. Well, I yield to you, Taku. You can have this article. This is too much like work for me. --Doradus 02:30, 24 Oct 2003 (UTC)

It's about time this article was moved to subroutine a term which is actually used by programmers, unlike subprogram which is hardly ever used, thus explaing why the word gets one of it's top 10 hits from Wikipedia. Mintguy