Talk:Programming paradigm

Introduction

I deleted the following sentence, because it does not make sense:

Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming.

Reasons for deletion: First-order logic is not a model of computation. Turing-machines are not specific to the OO and imperative paradigm. Turing-machines and Lambda-calculus are both universal models of computation and interchangeable. Imperative programming can be modeled by lambda-calculus. Functional programs can be compiled to Turing-machines. In practice, imperative programming relates more to Random-Access-Machines than Turing machines. — Preceding unsigned comment added by 138.246.2.43 (talk) 14:36, 17 April 2013 (UTC)

Hierarchy

I propose we work towards creating a paradigm hierarchy. For instance, procedural programming is a sub-paradigm of imperative programming, and both are structured programming paradigms. However, in the present state all of these paradigms are listed individually and the relationships between each are not as well defined as they could be.

Though, I recognize not all paradigms fit neatly into a hierarchy, but that information is useful to the reader in comparing paradigms. --DanDanRevolution 13:49, 6 April 2006 (UTC)

I agree, I think some sort of hierarchy ought to be imposed. Specifically, I was not aware of many of these "paradigms" and was expecting to just see "the big 5" (functional, object, imperative, procedural, logic) which seemingly ought to be featured more prominently. For instance, recursive is not something which is wholly exclusive of other larger scoped paradigms. --Belg4mit 22:40, 9 April 2007 (UTC)

I agree, too. I can't find my way around, at the moment... - Draketo 08:58, 19 July 2007 (UTC)

I agree. I think that there should be a clear distinction between programming paradigms and programming styles/techniques.

In my opinion it would be nice to include an example list of language following each paradigm and a picture showing sub-paradigm dependencies and/or paradigm "opposition". - BordaiGorl (talk) 09:59, 6 October 2008 (UTC)

Major list refactoring

I've made an initial effort to categorize the recognized paradigms in a well-defined, consensual hierarchy. I am trying to turn a list into a tree (or a small set of trees). The two major hierarchies I've created are 1) declarative programming (which contains "logic programming", "functional programming", "constraint programming", etc.) and 2) imperative programming (which contains "procedural", "OO", "aspect-oriented", etc.). I believe a well-organized hierarchy gives the reader more useful information for paradigm comparisons than an unorganized list of paradigms. I ask you to help me improving that classification and delimiting orthogonal hierarchies (e.g. "recursive" X "iterative"). --Antonielly (talk) 11:28, 15 October 2008 (UTC)

This seems to be a classification you just made up. Lisp is not a declarative programming language. --FOo (talk) 01:27, 16 October 2008 (UTC)

Both the article about declarative programming and the Category:Declarative programming languages consider functional programming languages as declarative (instead of imperative). See also the corresponding entry at Encyclopaedia Britannica[1], which says that both functional languages and logic languages are declarative. Of course, someone could define declarative programming in such a way as to exclude functional programming, but most of the material I've read about the subject (in books, papers, etc.) seem to conventionally imply "declarative" as a rough synonym of "non-imperative", which would include functional languages (as far as they follow the functional style, at least). For more authoritative material, see the academic papers and books listed in this simple search at Google Scholar: [2]. --Antonielly (talk) 11:01, 16 October 2008 (UTC)

Transference of the hierarchy to a separate template

User:LinguistAtLarge has had the smart idea of transfering the contents of the "Hierarchy of programming paradigms" section to the Template:Programming paradigms. This way, it will be possible to refer to the paradigms hierarchy in all the articles about every programming paradigm and give the hierarchy a better look and feel while still keeping the maintenance of the hierarchy centralized into only one place (the template). I agree with his idea. Since that template has been included in the article, I have removed the whole "Hierarchy of programming paradigms" section. --Antonielly (talk) 00:20, 22 December 2008 (UTC)

Dubious statements referring to 'Advances', rather than alternative approaches

'Dubious' tags added where thought appropriate and "some people believe..." type comments —Preceding unsigned comment added by 86.144.51.159 (talk) 07:15, 22 March 2009 (UTC) There is an implication that each 'paradigm' is superior to the previous one. The entire article needs much more work by an experienced programmer with much more insight into the true history of computer hardware/ software technology. —Preceding unsigned comment added by 86.144.51.159 (talk) 07:36, 22 March 2009 (UTC)

Code re-use

Modular programming in conventional languages (Assembler, Cobol, PL/1 etc) has been around since early 1960's (at least) and provided a very simple and much used method of code re-use (and functional 'isolation' as claimed for OOP objects) , as did in-line and Called subroutines, in-line Assembly language macros and other sophisticated pre-processors. —Preceding unsigned comment added by 86.144.51.159 (talk) 08:19, 22 March 2009 (UTC)

Below are old comments

Someone deleted Declarative programming. Why? 202.163.215.229 08:30, 8 September 2006 (UTC)

http://wiki.riteme.site/wiki/Comparison_of_programming_languages what is Mathematica now? Procedural or rulebased (as prolog)

I removed the redirect link since I think there's a place for a proper 'Programming Paradigms' page. The paragraph in the prgLang page is short and good for a prgLang page, but I believe a more in depth discusion should be worth while. Equivalently, I think we should have an equially short discussion of prgLangs, here.

I removed the Literate Programming link as it is not a programming paradigm, but rather a programming technique, specifically concerning program documentation. One can perform literate programming in C, C++, or in any other language that supports the tools. The reason why I think it is different is because literate programming doesn't relate to how the program is modeled, but rather how the program is documented. However, literate programming is (very much) important to mention somewhere, but most likely in another category.

Lambda calculus

In what sense does "lambda calculus stand above all the rest"? Certainly many languages are Turing equivalent; the current phrasing in the article is misleading at best. I haven't changed it because I'm not as familiar with LC as I should be -- but would a CS person care to comment? zowie 19:26, 2 May 2005 (UTC)

It is not accurate, in (at least) the following ways:

• The lambda calculus is not a programming paradigm. Nobody programs in the lambda calculus. (No, Lisp is not the lambda calculus.)
• A programming paradigm is not the same sort of thing as a notation for functions or algorithms -- it has as much to do with the way problems are analyzed as with the operations available to perform calculations.
• The way in which the lambda calculus is described as "standing above all the rest" is not in any sense unique to it. Many notations are Turing-complete, not just lambda.
• Turing-completeness has in any regard to do with equivalence to a Turing machine, not to lambda calculus. So if any notation were to be described as "standing above the rest" on this basis it would be Turing machines! But of course the point is that none are "above" the others if they are equivalent.

For these reasons I'm removing the claim. --FOo 01:50, 3 May 2005 (UTC)

Comments

I think there's a fundamental disconnect with this article and it starts with piece on lambda calculus. There is need of a bridge between the historical work and computing languages: Ada Byron developed some notation for the algorithmic computing, so programming paradigms should trace back at least to her. In 1963, John McCarthy wrote a seminal paper A basis for a mathematical theory of computation found In Computer Programming and formal systems. North-Holland. McCarthy's paper is a bridge from what we have today and the Church, Turing, Kleene work. McCarthy's basic argument was that recursive functions were the natural setting. Denotational semantics is the natural outgrowth of McCarthy's ideas by way of Strachey and Scott.

FatmarauderCU (talk) 17:50, 4 April 2012 (UTC)

Not a sentence

First line: A programming paradigm is a paradigmatic style of programming... THIS IS NOT A MEANINGFUL SENTENCE. Someone change it.

But it is hillarious! Said: Rursus ☺ ★ 17:12, 2 June 2007 (UTC)

Two edits

I removed the claim that C++ is designed to support AOP and "object-based programming". C++ isn't /designed for/ AOP (but may support it) and object-based programming seems like a loose term for object-oriented programming (already listed).

I removed the claim that Scheme is designed to support one particular paradigm. It supports virtually *all* known paradigms. It is biased towards functional programming, but this seems fine: Python and Ruby are as well biased (towards OO). And by the very tiny R^nRS and IEEE standards there are at least two direct supported programming paradigms from standard (functional and imperative). Scheme being extensible, we may take OO, logic programming and other common paradigms for granted, because they really are embedded in the language by most implementations. --189.12.148.237 22:09, 5 July 2007 (UTC)

Literate Programming?

Is there a reason, that Literate programming isn't included? Literate_programming - Draketo 09:00, 19 July 2007 (UTC)

Possibly because Literate Programming is more a style, or philosophy of programming, than a paradigm. I've always understood a paradigm to be more of a conceptual lens through which to understand a program, a "formal model" of what a program is. Literacy is a quality that one should strive for in their code. Literate programs can (and should!) be written in any paradigm. Mogunus (talk) 04:10, 26 March 2008 (UTC)

Copyright violation?

Hi, it looks like most of this article was just copied from the first weblink. What to do now? 85.177.183.213 (talk) 20:05, 23 January 2009 (UTC)

It's not always easy to tell whether material was copied from or to another website; in this case I suspect there may be a problem, since the linked text is not in the form of a Wikipedia article. Please raise this issue at Wikipedia:Copyright problems. Dcoetzee 21:36, 23 January 2009 (UTC)

Suggestions for improvement

Suggested improvement to the History section

It looks to me like the History section has become a bit tangled up do to a confusion between paradigms and languages. For example, I don't think that assembly language is a paradigm. It's entirely possible to write assembly code using any paradigm imaginable. It might not be elegant or productive, but it's possible. I've personally written code that shoe-horned an OO paradigm into ANSI C, a language listed as "procedural." It wasn't pleasant or pretty, but it solved the problem at hand better than any alternative I could come up with. I think that this confusion may have driven the long defense of assembly language in this section. It seems out of place, but I think I understand why someone felt the need to put it there. Nobody likes to see his favorite language under attack as outdated, particularly by someone who seems to know far less about the subject than he does. Before I jump in and attempt to rewrite the section in a way that clearly separates paradigm from language and avoids the appearance of declaring one paradigm fundamentally superior to another, I'd like to see if anyone objects or has other comments or ideas. Anyone? --Mike Duskis (talk) 17:12, 15 October 2009 (UTC)

"General-purpose programming languages" points here - WTF?

Some wiki nimrod, in their infinite ignorance, merged "general-purpose programming language" into domain-specific language (reasoning in elegant and pointless germanic logic that they were opposites and therefore obviously mergeable). This led to a circular reference, since the domain-specific language page was one of the main wiki pages referencing "general-purpose programming languages" (seriously, the wiki Vogons have got to learn how to proofread and check their changes... they aren't Gods, despite their personal notions).

Someone later fixed the circular link by linking "general-purpose programming language" to "programming paradigm" -- here.

But a "general-purpose programming language" is really just the opposite of a special-purpose programming language -- they exist in a two-state universe, i.e., general-purpose vs. special-purpose. They are NOT programming paradigms, but rather types of programming languages.

"General-purpose" means applicable to solving general problems. This would be the general class of most programming languages, like Fortran or Haskell.

"Special-purpose" means designed to solve a smaller set of problems in a well-defined context. For example, SAS is a language for writing statistics applications.

Yes, yes, we could have arguments about the language beasts that appear as general-purpose to one set of blind men (PHP), and as special-purpose to another set of blind men (PHP). You could probably do this for every programming language ever invented -- Fortran is for scientific formulas, Cobol is for business apps, Haskell is for humoring mathematicians, etc. etc.

In the previous section it was stated: "It looks to me like the History section has become a bit tangled up due to a confusion between paradigms and languages". This was in regard to sticking Assembly Language under "programming paradigms". This is the same problem -- you can cut the computer/software engineering cake many different ways... but some of the pieces from different cuttings just aren't comparable or even in opposition, they really cover different or overlapping topics and issues.

Computer languages are related to programming paradigms, but they are not paradigms in and of themselves. Computer languages are an implementation detail. A programming paradigm supports the big picture. How are we going to solve this problem? Not, with what gizmo are we going to solve it? Programming Paradigm equals Method. Computer Language equals Gizmo.

Some gizmos are high-level, some are low-level (like Assembly Language). Some gizmos are general-purpose, able to solve many types of problems, and some are special-purpose, most useful when trying to solve a much smaller set of specialized problems. But a gizmo is what you solve a problem with, it is not the method used to solve the problem. We need water. We dig a well. Digging a well is a paradigm. A post-hole digger is not a paradigm, even if it can be used for digging wells.

If the word Gizmo bothers you, substitute the word Tool instead.

When you hire your so-called computer expert from some WikiProject, hopefully he/she will know their ass from their elbow and will straighten out this mess.

I'm not holding my breath.
76.243.129.217 (talk) 17:06, 10 January 2010 (UTC)

Impolite but largely correct

While I have to object to the general tone of the anonymous comment above, I agree with most of the analysis. I think it underscores the point I made in the previous comment. We should make an effort separate programming language from programming paradigm. If anything, the article only deepens the confusion. Mike Duskis (talk) 19:49, 10 January 2010 (UTC)

Thank you, Mike

Rather than impolite, I like to think of my comments above as "tough love".

And what you wrote in your section on languages vs. paradigms, Mike, was both polite and spot on.
76.243.129.217 (talk) 11:37, 11 January 2010 (UTC)

I reacted to the top of the page comments

I understand the Wiki remarks about "citations for verification" and "needs attention from an expert in Computer science" The remarks and the replying angst reminds me how difficult it can be to compose the best English communication for ideas. The great number of programming paradigms means investing time for researching and integrating with the Wiki's articles and its portals. It will happen but over a long span of time. - Cheers, John S Woler (talk) 21:16, 30 January 2013 (UTC)

Is multi-paradigm a paradigm?

I have serious reservations about the usefulness of this term. For one, almost every language out there is a fusion of ideas and approaches; ergo multi-paradigm in some sense. And secondly, to say a language is multi-paradigm doesn't really tell you anything about the language. If you asked someone what kind of language Ruby is and they said "Ruby is multi-paradigm" you wouldn't go "Ahh, right, that's interesting," you'd go "OK. Which paradigms?"

My main objective in making this point is to remove "multi-paradigm" qualification from paradigm section of those side-info boxes on each programming language. The article of multi-paradigm itself serves as a definition for the term which may be useful to someone expressly seeking it out. Ruby is a particularly bad example as the side-info box lists Ruby's paradigm as "multi-paradigm" and nothing else, which tells you virtually nothing.

Another option is to limit our usage of the multi-paradigm term to those languages that merge the most significant paradigms especially where those paradigms are not normally seen together. For instance OCaml is an interesting merge of object-oriented and functional paradigms but a language that merges OOP and reflective really isn't interesting because many OO languages have reflective features. Oligomous (talk) 13:40, 4 March 2010 (UTC)

Agreed, multi-paradigm as a label is meaningless. We should change the sidebox heading "Paradigm" to "Paradigms" and then just list the paradigms. Multi-paradigm isn't a paradigm. Language to paradigm is a one-to-many relationship.

Regarding reflective features: I think what you're arguing is whether or not "reflective" is a paradigm. I say the notion of paradigm is pretty ambiguous - it pretty much means "consistent collection of language features enabling related idioms", which could be just about anything. So I think it's fair, if someone thinks of something as a paradigm, to let them call it a paradigm, and put it in the list. Qseep (talk) 22:48, 22 February 2011 (UTC)

When is a paradigm not a paradigm?

The articles states "A programming paradigm is a fundamental style of computer programming," and I agree. But, despite that definition, there seems to be a number of things listed as paradigms that I wouldn't consider so. For instance, is metaprogramming a "fundamental style of computer programming"? I'd say it's a style or with an associated collection of features and ideas. I know there were some esoteric languages created that exhibited aspects (as in aspect-oriented metaprogramming) as their primary means of abstraction (in opposition to objects, say) but these didn't work very well.

Whilst I like all these articles—reading about agent-oriented, intentional, or reflective programming is interesting—I'm hesitant to refer to them as paradigms when paradigms are fundamental styles or programming. Could they not be better classified as approaches to software construction or simply programming styles? Oligomous (talk) 13:55, 4 March 2010 (UTC)

"Style" is probably better than "paradigm". I think it's a historical accident that they're called "paradigms". Someone wanted to emphasize how much different their language was from others, so they labeled some subset of features a "fundamental paradigm" so they could market it better. Languages tend to become known by their distinctions more than their similarities. For example, most C++ looks exactly like C, but we say C is "procedural" and C++ is "object-oriented". It's what's different about the two languages that's deemed important.

In fact, look at the page for [Generic_programming]... it doesn't even call itself a paradigm. It calls itself a style. That sounds right to me.

What's happened these days is that the languages that were supposed to represent a single paradigm (Lisp, Prolog, Smalltalk, etc.) have been mixed and matched in so many ways into so many other languages, that every language is a mutt. Not to mention the additional styles that have been developed but haven't been seen to represent a whole language. Qseep (talk) 23:00, 22 February 2011 (UTC)

The Intro does not meet Wiki standards

The intro should be a jargon-free, self contained summery (or definition) of the whole topic. The sentence; "Paradigms differ in ..." seems premature since the term has not yet been defined/solidified. (Should it even be in the lead?) Focus: Making true statements about a subject is not similar to a definition/explanation. Suggest: Wikipedia:Manual of Style (lead section).
--69.227.84.108 (talk) 23:53, 27 May 2011 (UTC)Doug Bashford

The intro is short in being a complete overview and should include a summary of the article sections, but I don't think that sentence in particular is problematic. It's being used as an language-economic way to say "paradigms use concepts and abstractions to represent the elements [...] and steps [...] with each paradigm having a different collection of those"; which is a way to define the concept by signaling its primary properties. Diego Moya (talk) 15:01, 28 May 2011 (UTC)

Another way of saying what you are saying is that a word or term should not be used in the definition of it. In other words, the introduction should not describe a paradigm as being a paradigm. I think the main problem is that there is not a clear definition of the term. Currently object oriented programming is defined as a paradigm and I think that is a mistake. Sam Tomato (talk) 22:27, 27 January 2015 (UTC)

Haskell is single-paradigm ?

I beg to differ. Since Haskell implements an extremely flexible system for extension / APIs, you can effectively layer other paradigms in as domain specific languages.

http://portal.acm.org/citation.cfm?id=1863534 http://corp.galois.com/cryptol/ http://stackoverflow.com/questions/6622524/why-is-haskell-sometimes-referred-to-as-best-imperative-language

C generator DSLs: http://hackage.haskell.org/package/copilot http://hackage.haskell.org/package/atom — Preceding unsigned comment added by 74.125.59.1 (talk) 19:56, 18 July 2011 (UTC)

The concept!

I've always thought that the definition

A multi-paradigm programming language is a programming language that supports more than one programming paradigm

is malformed, since it's up to the programmer to decide what paradigmatic methodology to use. Since I wrote a LISP interpreter in C, then by that definition C is a functional programming language and thereby multiparadigm, and if any daredevil decides to implement a Smalltalk in Intercal, then Intercal is object oriented. Such a definition collapses by including every programming language, and must therefore be rejected for overlapping the concept of Turing-completeness.

Instead I believe a usable definition of multi-paradigm programming language must describe the base design, excluding the extra adaptions for differing programming styles. Rursus dixit. (^mbork³!) 13:28, 14 December 2012 (UTC)

Besides, I regard C-sharp as imperative-solely, and F-sharp as functional-solely, building on the traditions of imperative-solely Java and functional-solely SML. Every modern imperative and modern functional PL has objects. Leda is another story. Rursus dixit. (^mbork³!) 13:32, 14 December 2012 (UTC)

Dubious

The list of programming paradigms has no valid source, but instead a HTML comment explains its source to be Template:Programming paradigms!! Which means a process where any editors random (mis)comprehension of the word "paradigm" authors Wikipedia. Also, consider Wikipedia as the academic source for Wikipedia (Wikipedia:Wikipedia is not a reliable source)! I want some list of programming paradigms out there. I know there are. Rursus dixit. (^mbork³!) 21:11, 26 December 2012 (UTC)

C++ is not OOP accordingly to the creator of Object-Oriented Programming

Consider C++ to be removed, as C++ is not a representative of an Object-Oriented Programming Language, accordingly to Alan Kay, the creator of the paradigm. If no objections, I will remove it. — Preceding unsigned comment added by Hernan mvs (talk • contribs) 11:25, 15 February 2013 (UTC)

I think it is over the top to remove C++ from the list. C++ may along with others need to have better descriptions as to their included paradigms' characteristics. I can't say I find that any language using any paradigm is a pure version of an idea. C++, Java, C#, and others are at best procedural and object-oriented hybrids from the C-language. That does not mean they can't be described as being object-oriented. I suggest improving ways to describe various paradigms and the ways languages include paradigms'ideas. - Cheers, John S Woler (talk) 20:44, 15 February 2013 (UTC)

Who is Alan Kay? C++ was designed and implemented by Bjarne Stroustrup. Sam Tomato (talk) 22:31, 27 January 2015 (UTC)

Okay I did some research. Alan Kay on Object-Oriented Programming says that Alan Kay says Object-Oriented Programming "could be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." In other words, he thinks that only Smalltalk and LISP are OO except possibly something obscure that he is not aware of. Sam Tomato (talk) 22:52, 27 January 2015 (UTC)

I was in the audience for an Alan Kay keynote once and this is 100% true. For Kay, object-oriented programming is not about what the programming language looks like, it is creating software environments using direct manipulation in a GUI and using programming to script behaviour of the objects shown in the GUI. This is what Smalltalk allows, HyperCard, Visual Basic, Delphi, .NET languages with GUI-manipulating IDEs, etcetera. I don't think this is what the term "object-oriented" is taken to mean by 99.9% of the people who use it. Some people use "visual programming" to describe it, but that term can also have other meanings. Rp (talk) 09:40, 29 January 2015 (UTC)

That would be more of describing the way programming is done by having objects and handling associated events, what is usually thought of as GUI programming; that is not the way object-oriented programming would be described in general. — Dsimic (talk | contribs) 21:06, 29 January 2015 (UTC)

No, "GUI programming" is not what Alan Kay means. You also need an environment that lets you create and modify the GUI graphically, without programming. For a compiled language, this means the GUI programming code is generated automatically and the designer normally doesn't even need to see it. I agree this is not what the article should define as object-oriented programming, but it is what Alan Kay means when he talks about it. Rp (talk) 11:16, 30 January 2015 (UTC)

Well, now I might be slightly confused. :) Does he refer to the programming tools that automatically generate "code behind" the GUI elements, so a developer (or whoever deals with the GUI elements) never needs to write it by hand? In that case, the real programming is all about filling in event handlers and such stuff, beside implementing the internal program ("application") logic. If that's what he speaks about, then I'm not so confused. :) — Dsimic (talk | contribs) 12:54, 30 January 2015 (UTC)

Yes, but historically, that is the wrong order of thinking about it. First there was Simula (which didn't really have a GUI system, as far as I know). Then there was Smalltalk, which Kay worked on; it came with all this. Then came C++ which was based on C and Simula, not on Smalltalk; again, no GUI support. Then came OO-based GUI programming without GUI builder support , e.g. X programming or GUI programming in C++ or in Java. I think what Kay was saying in that keynote is that that just misses the whole point of what he was trying to do. Rp (talk) 17:16, 1 February 2015 (UTC)

Anyway, tying object-oriented programming exclusively to GUI programming might not be the best thing to do. — Dsimic (talk | contribs) 17:33, 1 February 2015 (UTC)

Header section

Thanks to whomever caught the Declarative edits. I've read the article multiple times and missed that edit. - Cheers, John S Woler (talk) 20:49, 19 February 2013 (UTC)

"Criticism"?

Not sure what the "Criticism' section is doing here. This article does not attempt to classify programming languages. Rp (talk) 12:12, 19 October 2013 (UTC)

It still isn't clear to me. Overall, I think this article could be rewritten to be more compact and to make it clearer that a programming paradigm is a style of programming, not a way to classify programming languages. Rp (talk) 14:44, 25 September 2019 (UTC)

me too bro 2001:660:6101:800:204:0:0:10 (talk) 17:12, 4 January 2023 (UTC)

@Rp I agree with you(see my comment at the bottom) and will make the change unless someone objects. Digital27 (talk) 11:12, 21 November 2023 (UTC)

Symbolic Programming

I don't see symbolic programming anywhere in the article or its template. And it's hard to find it mentioned in other programming pages, even though source says it applies to Lisp and Prolog. Where should it go? Abstractematics (talk) 18:53, 20 November 2013 (UTC)

Hello there! That'a a great addition, already went ahead and mentioned symbolic programming in the lead section. It should be further described within the "History" section. -- Dsimic (talk) 19:24, 20 November 2013 (UTC)

... done. :) -- Dsimic (talk) 00:58, 21 November 2013 (UTC)

Concept Programming

I don't see Concept Programming wiki.riteme.site/wiki/Concept_programming in Template:Programming_paradigms. — Preceding unsigned comment added by 2.235.73.55 (talk) 23:27, 22 January 2014 (UTC)

Dull and unclear

I know a little about specific programming languages but I think I know less about programming after reading this article.

I've read through the article twice and I think more vivid and descriptive language could be used to describe the differences between paradigms. How about some quotes from scholars who created these languages or defined these paradigms? Or some examples or analogies. And that flow chart is a complete mess, it is overly detailed and looks like it belongs on another article. I think 95% of the terms in the image are not even mentioned in the article.

This is an article for a general reader and, considering what an important subject this is, this article is just a wall of dull text (blah blah, blah blah blah) that neither engages the reader or makes them curious to learn more. It's an interest killer. Liz ^{Read! Talk!} 21:50, 5 June 2014 (UTC)

Hello there! Hm, article looks fine to me; at the same time, I'd agree that it might be a bit dull and perhaps a bit too complicated, but it's quite tough to explain such an advanced topic in plain words that would be understandable to just everyone. In other words, my opinion is that any significant simplification would lead to lost details, what wouldn't be a good thing. — Dsimic (talk | contribs) 20:27, 8 June 2014 (UTC)

What would probably improve this a lot without removing any detail is an example. Say, comparing a functional vs. object-oriented vs. service-oriented Hello World. -- Beland (talk) 00:11, 23 August 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Programming paradigm. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20090320002214/http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf to http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 03:58, 17 October 2015 (UTC)

Object-oriented section

This should reference the main article: https://wiki.riteme.site/wiki/Object-oriented_programming

Easy change for someone who knows the wiki syntax, but I don't know the conventions off the top of my head. — Preceding unsigned comment added by 160.83.42.135 (talk) 10:11, 15 December 2015 (UTC)

 Done, added a {{Main}} link to the Object-oriented programming article. — Dsimic (talk | contribs) 08:14, 10 January 2016 (UTC)

Simulation Language

Hi,

Could we create a section for Simulation languages ? Could we say that Continuous simulation or Discrete event simulation are programming paradigm ? — Preceding unsigned comment added by 90.96.193.0 (talk) 10:55, 6 August 2016 (UTC) https://wiki.riteme.site/wiki/Simulation_language https://wiki.riteme.site/wiki/Continuous_simulation https://wiki.riteme.site/wiki/Discrete_event_simulation

Aspect-oriented Programming

Aspect-oriented Programming_(AOP) appears not to be mentioned in particular. I think it should be.
See: https://msdn.microsoft.com/en-us/magazine/dn574804.aspx?f=255&MSPPError=-2147217396
or: https://wiki.riteme.site/wiki/Aspect-oriented_programming

Read either of the citations for an exact description.

An over simplistic overview:
AOP is a declarative programming paradigm that is usually applied to an OO or Service Oriented Architecture; Although it could be used in any paradigm. Some would say it is of itself not a new paradigm rather a mixture of declarative and other paradigms.

AOP cross cuts concerns. e.g. Logging needs to be applied to all aspects of an application. However, you do not want to hard code logging into every point you want logged; e.g. informational logging at every entry and exit of a method. This would break the DRY principle.

You write the code once and declare an Aspect in the main program to tie that code to all the places you want that code called and the insertion of the code is done as part of the build process.

Robin Murison 2018/08/08

I don't think this is really a paradigm. It got a lot of press for a while, and it has a few implementations, but I'm not aware of any AO languages; as far as I'm aware, implementations are preprocessors available for some OO languages. I'd call it a technique rather than a paradigm: it doesn't fundamentally change how programs express what needs to be done. Then again, C++ started out as a preprocessor for C, and C#'s extension methods are AO-ish. Rp (talk) 19:18, 8 August 2018 (UTC)

Programming Paradigm vs. Programming Language Paradigm

It seems to me that we should separate programming paradigm (or style of programming) from programming language paradigm. While certain programming languages supports/encourages certain paradigms, many paradigms/styles are independent of programming languages. For example, event-driven programming can be done in many languages. Digital27 (talk) 12:05, 17 November 2023 (UTC)

I agree with this, as far as I know Declarative Programming is not a paradigm. functional paradigm is. I'll try to find any reliable references pointing to that. —Nanami73⚓ ^{(talk) (contributions)} 23:33, 17 December 2023 (UTC)

@Nanami-seven-three Thanks for your reply! Let's see what we can do to improve it. Digital27 (talk) 02:19, 18 December 2023 (UTC)

This might be one of the best suggestions so far. This page is a mess and judging by the large number of competing suggestions in this talk page, I'm not the only one that feels this way. It could use some simplification and splitting off the "Programming Language Paradigms" might be the best way to do so." 206.123.227.66 (talk) 16:07, 26 November 2024 (UTC)

what is a programming paradigm

First sentence: "Programming paradigms are a way to classify programming languages based on their features." is not wrong, but so generic it lacks value. There are many ways to classify languages (or anything). The programming paradigm is a rather particular way to do so. I agree that it's hard to describe, but someone needs to take a stab at a real definition. The second paragraph takes a shot at it by listing some examples, but examples are not a definition. What is it?

Oxford says paradigm is "a worldview underlying the theories and methodology of a particular scientific subject." I'd say that is close.

How about: Pervasive conceptual view that a language is designed to model.

Stevebroshar (talk) 18:19, 31 January 2024 (UTC)