Talk:Procedural programming

From Wikipedia, the free encyclopedia

Contents 1 "Procedural" v. "Imperative" (merge?) 2 Rewrite 3 Procedural Programming subset of OO? 4 Procedural vs. Declarative 5 Efficiency Claim 5.1 Proof of efficiency 6 C# and Java as Procedural Languages

[edit] "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)

[edit] 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)

[edit] 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.

[edit] 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"?

[edit] 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

[edit] 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.

With PP:

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

With OOP:

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)

[edit] 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.