Talk:Procedural programming/Archive 1

Archive 1

Procedural vs. Declarative

The concept of procedural languages is used to contrast with declarative languages. Some languages have features of both, such as LISP or other functional languages (which are not primarily declarative as the declarative language article states). The difference is procedural describes "what" a program does and "how" it does it. Declarative simply states the form of what is expected (Logic-based programming). I would suggest someone clean this up and add it/ edit this article (I have never done so, and don't know if I should dare make this my first). More detailed information can be found in Concepts of Programming Languages by Robert W. Sebesta. OO being a subclass of procedural is a tough call. It is certainly more procedural than declarative, but OO describes a different set of ideas than procedural or declarative. (abstraction, inheritance...etc..) It seems possible that there could be an OO logic-based language, so I would say OO is not only procedural. Also, the opening statement includes: functions should not be confused with mathematical function, seems wrong. They should be confused / thought of as nearly the same. I am sure there is article on here further detailing this: given input a function produces a single output. -has

O'Haskell is an example of a technically non-procedural OO language. The non-proceduralness is buried under a lot of syntactic sugar, but it's there. ML and Lisp are both functional languages where the functions can have side effects, which makes them distinct from mathematical functions. Gazpacho 04:52, 27 October 2005 (UTC)

What are these side-effects? In Common LISP and other versions sure there are side-effects, and in fact there are many things which make Lisp actually imperative. However, in pure Lisp, which is a true functional language, then I can not think of any side-effects. When you use a subroutine to simply return a single value, then it is considered a function. The term function is not defined by what languages have made functions and then expanded to make something different than functions. It is a term in programming originated from subroutines that are true functions, as in like mathematical functions. Programming languages on computers are no stronger than recursively enumerable langauges which can be enumerated according to recursive functions, which are highly "mathematical". Basically, I am saying every program could be written as a set of mathematical functions (it may be a huge list of them, but it is possible - you learn this in the study of formal languages). -has

If you consider "Lisp" as a Platonic ideal, you can make it have whatever properties you like. But real Lisp allows side effects and Lisp programmers routinely make use of them. Therefore the mathematical functions in a typical Lisp program do not line up with the language's functions. Gazpacho 05:38, 27 October 2005 (UTC)

I think the previous poster meant to say Lambda Calculus, not pure lisp, which I am not aware of actually existing. However, if we limit discussion on this page to languages that are only declarative, then we are looking at a very small set, indeed (lambda calculus,...). More interesting, I think, are the languages which are practically declarative (which includes the lisp variants, etc.).

That being said, if you, -has, have a way to improve the article, then by all means do so. You can start by placing your changes here and I (and hopefully others) will comment on them. If they are good suggestions, then they will be adopted, but even if they're not, it might lead to something better. --Andrew Eisenberg 21:46, 27 October 2005 (UTC)

PJTraill 18:00, 7 May 2006 (UTC) Surely the usual dichotomy is between "declarative" + "imperative". I have indicated that "procedural" may mean "using procedures" or "imperative", and think it reasonable that this article describe only the former sense. Or is there a third sense of "procedural"?

Efficiency Claim

There was an efficiency claim under "Comparison with object-oriented programming" that I removed. There are two reasons I did this.

1. The claim is a generalization without a reliable source.
2. The claim is actually false.

From Effective STL by Scott Meyers, p.203:

"The fact that function pointer parameters inhibit inlining explains an observation that long-time C programmers often find hard to believe: C++'s sort virtually always embarrasses C's qsort when it comes to speed. Sure, C++ has function and class templates to instantiate and funny-looking operator() functions to invoke while C makes a simple function call, but all that C++ "overhead" is absorbed during compilation. At runtime, sort makes inline calls to its comparison function while qsort calls its comparison function through a pointer. The end result is that sort runs faster. In my tests on a vector of a million doubles, it ran up to 670% faster, but don't take my word for it, try it yourself. It's easy to verify that when comparing function objects and real functions as algorithm parameters, there's an abstraction bonus." (parenthetical statement removed, italics in original)

If you disagree and have a better source than Meyers, I'd be very interested to "talk shop" about this. :-) Cheers. /* Pradeep Arya 09:33, 11 January 2006 (UTC) */

I disagree. You're arguing for generic programming, not OOP. Generics in C give the same speed. -- Anon March 5

Proof of efficiency

Think in a single program with just one function (hello world for example). Mission :the program must call this funtion once then close. It's only a illustrative example but it can be extrapoled for a more complex sample if you are please to.

You must create the function then call it, then return the result and finish the program.

You must create a class with the unique function, the instance the object of this class, then call this object. Next, you must return the result, then must destroy the object and finish the program.

The resource spend and speed are clear, also you can see a tendency. --Magallanes 14:58, 11 September 2006 (UTC)

C# and Java as Procedural Languages

The fact that C# is included in the list of procedural programming languages but Java is omitted. It seems to me that the only support both languages have for procedural programming is made possible through the class construct, which is an inherently object oriented construct. While I'm not sure I want to start a war over whether this support is enough to consider the languages procedural, I would think that given their similarities, either both should be included or both should be omitted. For now, I've added Java, but I think this might warrant more discussion. Taft 20:03, 3 March 2006 (UTC)

PJTraill 17:53, 7 May 2006 (UTC) I've extracted both from the list, added a criterion for this, mentioned both there, left C++ in with minor changes to the comment.

I do not think classes is inherently object oriented. What if I make a C# or Java -program consisting solely of static methods? Would you call that an object oriented program? It would essentially be like programming in C. Thus C# and Java supports procedual programming. 195.7.30.16 14:10, 26 October 2007 (UTC)

Procedural Programming subset of OO?

Is procedural programming a subset of object-oriented programming? Seems to me that all OO languages are procedural as well. Is it possible to be OO without being procedural? If not, then this should be mentioned in the main article under the section on OO. --Andrew Eisenberg 19:05, 31 August 2005 (UTC)

OO programming is a subset of procedural programming, the opposite is incorrect. So it's not possible to be oo without being procedural but it's possible to be procedural without be OOP.

What about OCaml? Lisp can be used in an object-oriented manner as well.

"Pure" object-oriented languages have encapsulation to a degree which forbids certain aspects of procedural programming, such as calling a function from any point in the program or referencing global variables without a registry. In this respect, I think it is appropriate to consider OOP as not a superset of procedural programming, but rather a separate style. Another consideration is the compiled result: Does an Objective-C program compile to objects, or are these merely abstractions for bundles of procedural or imperative assembler in the mind of the programmer? 216.19.189.159 (talk) 10:52, 6 June 2008 (UTC)

Comparison with object-oriented programming

The table in the comparison with object-oriented programming section describes the difference in idioms between pure OO and pure procedural programming, not the difference in features, as both have functions, both have variables, and so forth. In OOP a message is information sent to a method, just as in PP, an argument is information sent to a function. Therefore the proper mate for "message" under the OO paradigm in this table is "argument." A "function call" is not information sent to a function, but rather the instantiation of the function itself, much as an object is not a class, but an instantiation of the class itself. —Preceding unsigned comment added by Max42 (talk • contribs) 23:02, 6 June 2008 (UTC)

Procedural Programming != Procedural Generation

Spore is listed in the Procedural_programming#Games section. I suppose that the person who added it was as confused as the rest of the world regarding the term Procedural programming, often (ab)used to describe Spore's unique content. In fact, the correct term is Procedural generation, which is what Spore does. I know that a lot of people refer to that as Procedural Programming nowadays, but that's just incorrect. (Not that I care, it's just hilarious when it results in articles such as these)

Now, I'm not going to remove this right now, I want to discuss this first. The thing is, the whole section being there doesn't make sense. Elite, Quake, Quake 2, Quake 3 and of course Spore are all written in an Object oriented programming language. If anything belongs in there it's.. oh I don't know.. Pac-Man? --ShadowCode 20:47, 5 August 2007 (UTC)

• edit* One more thing. The reason why everyone is saying procedural programming while they mean procedural generation is because some PR idiot at EA has been using that term to describe Spore. And you know, the press just takes it over and sooner or later everyone is talking about procedural programming. Gotta love hype and the buzzwords it generates, 'eh? --ShadowCode 21:00, 5 August 2007 (UTC)

I created the "List of Popular Software written using Procedural Programming" section because I was interested in knowing if ANY popular programs nowadays were written in a procedural programming style ( research ). I could not find such a list on the internet and thouht this would be a great place to put it. Personally, I can only list very few popular programs written using procedural programming. Yes, I listed Quake, Quake 2, Quake 3 because they ARE written in C using a procedural programming style. Source code for all those games are available online.--24.8.150.120 23:55, 14 August 2007 (UTC)

Someone already removed Spore (altough for pretty much the wrong reason. Oh well.) --ShadowCode 09:01, 6 August 2007 (UTC)

I have removed Spore because it isn't a popular game yet.

I've removed it once, because there exists no sort of sources on the claim. Until such a source exists, putting it there is pressuming something very unlikely. Presuming in general isn't very much in the spirit of Wikimedia. User:or-whatever (talk) 11:27, 19 August 2008 (UTC)

List of Popular Software?

The list of software seems to be way too bloated, unmaintained (it's not even properly capitalized), and pretty much unnecessary. I suggest either a clean-up or a complete removal of the "example software" section. I guess I'll do it myself if no objections pop up. —Sykopomp (talk • contribs) 05:45, 5 October 2007 (UTC)

I object to your removal of the section. I put it in there for research purposes. You are welcome help edit the section. —Preceding unsigned comment added by 24.8.200.98 (talk) 07:24, 21 October 2007 (UTC)

I have edited the section because some people confuse procedural programming with procedural generation.

Also, there is no proof, that I could find, that some of the programs listed were written using procedural programming.

(Quake and Doom sources are widely available and written using C.) —Preceding unsigned comment added by 24.8.200.98 (talk) 07:48, 21 October 2007 (UTC)

I believe that this section ought to be removed as well. The list has little to do with procedural programming itself and is woefully incomplete, seeing as it should include pretty much every C program in existence. Perhaps notable instances of procedural programming should be added to prose sections where they add to the article, or a list of procedural languages used instead, but a list of programs written using procedural programming doesn't seem particularly useful or relevant. CapitalSasha ~ talk 05:50, 6 December 2007 (UTC)

The "Popular Software" list is useful and relevant because it gives the reader some examples of programs written using the procedural programming style. "Popular" was chosen to keep the lists contents short.--75.71.71.76 (talk) 18:20, 23 December 2007 (UTC)

I reckon it is pretty useless, as they could just as well have been written in different paradigms. The user sees the function, not the technique. A reference to source would be more relevant. PJTraill (talk) 22:39, 16 April 2008 (UTC)

I think it has a great purpose of providing the reader with some examples of popular programs written using a procedural style. This is great for such things as knowledge and research.

The list should be removed. To me it looks like an advertisement for these particular software. I would much rather prefer to see the use of procedural programming in general being mentioned somewhere in the text. // Fulkkari (talk) 07:41, 11 May 2008 (UTC)

The list is suppose to give the reader some popular examples of programs written using procedural programming. Most of the software listed is available as open source. This way the reader can see some examples of programs written using the procedural programming style. Yes, this whole list is an advertisement for procedural programming! Yes, the reader can actually see some GOOD examples of procedural programs that have actually worked in the real world -despite some false reasonings by some in the OOP community that procedural programming leads to unproductive spaghetti code. --76.25.205.169 (talk) 21:50, 15 May 2008 (UTC)

I have a note on this too. What is Spore doing in that list? If it's programmed using a procedural language, there should at least be a reference. Though my guess is that it's not, because very few big game productions are made with procedural languages these days, and why would a team, who have never made games in anything but OO languages, suddenly change it? Besides, handling all that user created content would be a lot easier in an OO lanugage, than in a procedural one. My guess is that someone has misunderstood the term Procedural Generation (game content being generated procedurally by the players), for being programmed with a procedural language. I may be wrong though? Or-whatever (talk) 01:15, 17 August 2008 (UTC)

I've removed the section, and it sounds to me like I'm not going to have many objections. (To be honest, I'm surprised it hasn't been done yet.) There is simply way too much software written in languages like C to be able to fit into a list. If items on the list are truly notable, they should be incorporated into the article body. If such a list is to exist at all, it should be in its own article, not here. — ^FatalError 00:25, 25 September 2008 (UTC)

"Procedural" v. "Imperative" (merge?)

Why does this article include this tag? This article should be merged with imperative programming. Procedural programming and Imperative programming are orthogonal concepts, and can be best left on their own. Bevo 19:16, 14 Feb 2004 (UTC)

I've just grabbed a couple of sentences from FOLDOC to explain why. -- Kowey 11:06, 3 Apr 2004 (UTC)

The distinction seems to be quite subtle, and could be clearer. I for one don't understand it ;). Could we say that Procedural programming describes a set of rules that are also common `design guidelines' in other paradigms, like for example imperative programming? Obviously breaking up a program in modules and having scoping rules is something common in imperative programming. --Raboof 12:22, 13 Apr 2005 (UTC)

I can't pretend that I fully understand the definition either, but it would appear that procedural programming describes something which is so embedded in programming styles that it's taken for granted. Imperative languages divide their code up into files (C), or classes (C++, Java); some functional languages divide the code up into modules (Haskell, SML) and classes (OCaml) for the same reason. I assume logic programming languages do something very similar. Surely only the very simplest programs written nowadays are in the form of one monolithic main() method! :) 129.215.13.84 28 June 2005 16:49 (UTC)

PJTraill 18:05, 7 May 2006 (UTC) See my comment under Procedural v. Declarative (18:00, 7 May 2006)

Traditionally, "procedural programming" is pretty much synonymous with "imperative programming" in that it refers to programs being "recipes" for the steps to be performed, as opposed to "implicit", "goal-oriented", "constraint-based", or "requirements-based" programming wherein the functional requirements and constraints are specified and the language implementation itself devises the steps to satisfy the requirements. — DAGwyn 19:52, 18 June 2007 (UTC)

I think an assembly language program would be imperative, but might not be procedural. So don't merge as they are different concepts. But any 3GL which is imperative should also be procedural. Aarghdvaark (talk) —Preceding comment was added at 22:49, 24 December 2007 (UTC)

I agree that the distinction is subtle, and that assembly language programs are imperative but not procedural but that if the language has procedures (i.e., void or unit type functions, it qualifies as procedural. Generally, imperative programming is a paradigm based upon statements and statement types with sequencing, whereas procedural programming is based upon function application with "no return value", i.e., procedure calls. (In functional programming, that should properly be unit type.)

I think high-level imperative programming languages are de facto procedural because AFAIK they all include function application, but there are imperative features that are not intrinsically related to functions. For example, associated features of a programming language such as mutable state, especially assignment, are also referred to as "imperative" in programming language parlance, but I don't think these are necessarily procedural features. Banazir (talk) 22:59, 21 April 2010 (UTC)

Rewrite

Hopefully this clarifies the distinction between the procedural and imperative programming paradigms, and hopefully my understanding of these concepts is reasonably accurate. Revisions, clarifications, and corrections are welcome... -- Beland 07:07, 11 July 2005 (UTC)

I think you did a good job, but there are still some ambiguous points, such as the implication of the following statement: "Procedural programming can sometimes be used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm, derived from structured programming, based upon the concept of the procedure call." Imperative programming is itself identified as a programming paradigm as well, and here it reads as if procedural programming is a paradigm but not necessarily imperative programming. I suggest something that sets procedural programming apart as its own paradigm, either a strict subset of imperative programming or "typically a subset save in boundary cases". -- Banazir (talk) 23:03, 21 April 2010 (UTC)

This sentence is not a reason

Comment about this sentence: "Procedural programming languages are also imperative languages, because they make explicit references to the state of the execution environment." It might (perhaps) help someone like me reading this if "execution environment" were actually defined. It is used twice in this article (at the time of writing this) without being defined or explained.

How does making "explicit references to the state of the execution environment" make a language an imperative one? Earlier in the article, it is suggested that imperative langauages specify the steps the program must take to reach the desired state. That makes sense. Specifying what must happen chimes with the word "imperative". Making "references to the state of" something (something that isn't even defined) doesn't make sense as a reason, and is very abstract and confusing. Even if "execution environment" were clearly defined, the above sentence is most probably not an explanation why "Procedural programming languages are also imperative languages". 109.145.82.159 (talk) 17:23, 19 August 2011 (UTC) — Preceding unsigned comment added by 109.145.82.159 (talk) 17:17, 19 August 2011 (UTC)

Module object equivalence

There's nothing dubious at all about this. A module is a collection of shared state (stored in module-level globals) combined with a set of functions that operate on that state. An object (in the sense of class instance) is a collection of shared state (stored in 'self') combined with a set of functions that operate on that state (i.e. methods). The only really substantial difference between the two is that -- generally -- modules can only be instantiated once, while there can be multiple instantiations of the same class. If no one disputes this, I'm deleting this tag. 72.228.33.213 (talk) 18:23, 15 September 2011 (UTC)

The multiplicity difference is not a minor point; modules are thus much more akin to classes. I've edited the article to make better comparisons. --Cybercobra (talk) 03:58, 16 September 2011 (UTC)

Totally screwed up

The definition given is in marked contrast to the definition here: http://encyclopedia2.thefreedictionary.com/procedural+language

That second definition is essentially the one I learned in college in the early 70s. I believe the entire article needs to be rewritten. drh (talk) 19:46, 16 December 2012 (UTC)

I agree!! In the above link the first defination covers all procedural languages.

The clasic programming language COBOL first coined the expression procedural language. Its designers calling it a procedural programming language.

COBOL was designed as business language mainly for accounting and inventory controle applications. It is an acronym for COmon Business Orianted Language. There were other procedural languages. FORTRAN and ALGOL were called procedural languages.

Learning programming in the late 1960 I know that termonolgy has changed over years. This should be a place were people can find answers. Technology changes and termonolgy with it. A part of the problem is that programming is a vocation and computer science is an academic endeavor, or was when I was in collage. COBOL was tought as a vocation. It was fairly unique. Only one other language used a like control structure. The COBOL PERFORM statement was kand of a subroutine call. But it just made a section of code a subroutine. COBOL code was organized into paragraphs each starting with a lable. Say we have several code paragraphs labled in order: A B C D.

We can say:

 PERFORM B THRU D. and in another say
 PERFORM A THRU C.

The old COBOLs also used PERFORM as their loop operation

 PERFORM F FOR J=1 TO 5.

Sorry if incorect syntax. It's been 40+ years sense I've seen COBOL. That first statement about using a call stack is impossable as several machines back then, that were designed for business application did not have registers.

I started programming in 1965. A lot of changes over those years. Steamerandy (talk) 01:49, 25 November 2018 (UTC)

Irrelevant: Java the 1st major OP language.

There is, in the section comparing the paradigm with OO, a claim, recently tagged with {{citation needed}}, that Java is the 1st major OP language. I would be inclined to remove this assertion completely, as it is somewhat tendentious and not illuminating in the context of the comparison. Does anyone feel differently? PJTraill (talk) 00:59, 27 November 2018 (UTC)

Copyright problem removed

Prior content in this article duplicated one or more previously published sources. The material was copied from: https://www.techopedia.com/definition/21481/procedural-programming. Copied or closely paraphrased material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.)

For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, and, if allowed under fair use, may copy sentences and phrases, provided they are included in quotation marks and referenced properly. The material may also be rewritten, providing it does not infringe on the copyright of the original or plagiarize from that source. Therefore, such paraphrased portions must provide their source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. Sam Sailor 06:59, 21 June 2019 (UTC)

References lead to pay wall.

What good are reference links that just lead to a pay wall? Is someone trying to sell something? Should pay walled references be removed? I think so. — Preceding unsigned comment added by 74.128.121.174 (talk) 23:15, 22 September 2019 (UTC)

Policy is at WP:PAYWALL. --David Biddulph (talk) 19:25, 24 September 2019 (UTC)

Origin of terms

I was under the impression that the term "procedural languages" was originally synonymous with what we mean by imperative programming today. At least, back in the early 1990s when I started learning how to write in BASIC, I heard of the classification "procedural language" and the programming style it describes, but did not hear about "imperative" programming until a few years later. What's the actual story -- when were the terms introduced and when did their meanings diverge so that "procedural" implies something more specific than "imperative"? According to Google Ngram, "procedural programming" gradually appeared in the early 1960s, rose sharply from 1980-1990 and then declined, while "imperative programming" was flat until around 1979, then rose sharply with a similar shape (but smaller). It would be great if anyone has some references pointing to early definitions of the terms. Destynova (talk) 06:42, 9 December 2021 (UTC)

This article should be removed. Procedural abstraction is prevalent in every programming paradigm

There is no procedural paradigm as such. Any algorithm is a sequence of steps transforming an input (possibly null) to some answer, it does not matter if such language is imperative or declarative. Imperative languages compute by mutating the state of memory, a program is a composition of such instructions with the help of control statements, functional programming does the same by composing functions. OO programming created a lot of confusion, because instead of writing code composed with instructions, in OO it is supposed that objects are sending messages to other objects, those messages order to perform some procedure called object's method. The main difference is an exacerbated use of encapsulation which induce an anthropomorphic approach to the problem.

Is procedural programming implementing algorithms in a procedural language? That's probably the source of confusion.

What can be said if procedures are implemented with coroutines? — Preceding unsigned comment added by 2806:106E:B:53E6:F9:F69F:2ED7:3753 (talk) 08:48, 2 September 2022 (UTC)