Template talk:Programming paradigms

Response to apparent arbiter of English

Mathematical Programming is both a paradigm of Mathematics and simultaneously one of Computer Programming and is actually better established as the latter than any of the others in the (current) list as such, being roughly co-eval with the development of electronic computing. I hope I don't have to document this. Lycurgus (talk) 14:45, 10 January 2009 (UTC)

Also, if I were to follow the (relatively lax/sloppy usage) of the rest of the template I could add some subparadigms such as the Informatik approaches to creating information systems as optimization problems on the domain of problem information flows such as those of Langefors, et. al., cost and sizing/estimation paradigms such as those of Barry Boehm, et. al. 72.228.150.44 (talk) 14:50, 10 January 2009 (UTC)

It is nice to know that there are more people interested in improving this template. In my opinion, a good way to proceed to reach consensus about the inclusion (or non-inclusion) of Mathematical programming (or any other element presented here as a programming paradigm) is as follows.

I think we should document here only programming paradigms that were declared as so in the corresponding articles and accepted by a consensus among the editors of the individual article in question. For instance, if Mathematical programming is indeed a programming paradigm, then this should be first documented in the corresponding article (together with the citation of one or more reputable sources) before adding a new entry to this template. This way we will be able to keep in this template only entries which have achieved consensus in the corresponding articles, thus freeing this template from most potential disputes.

As to the sloppy usage of "programming paradigm" for the current entries of this template, the template contents are always open for review. In that case, feel free to create one section in this talk page for each entry that you want to challenge. We are open to listen to you and to collaborate with you in improving the contents of this template. --Antonielly (talk) 16:33, 10 January 2009 (UTC)

Adding the template to the involved pages

I think we should follow the example of most other "categorical" templates (such as Template:Software Engineering and Template:GUI widgets) and add this template to all the articles referred to by it. However, the current layout of this template is cumbersome for adding it to pages other than Programming paradigm. For instance, I have made two attempts to make it fit an article, but it didn't fit well due to layout issues. I believe we should change it somehow, but the new layout should still preserve the hierarchies of programming paradigms and (if possible) the highlighted contrasts of "opposing/dual" paradigms. How could we remedy this? --Antonielly (talk) 17:07, 21 January 2009 (UTC)

One solution could be to keep {{Programming paradigms}} as it is (as a vertical navigation template), and create a horizontal version perhaps {{Programming paradigms footer}} for use at the bottom of the page. With a horizontal version it might be harder to show hierarchy though. Both templates would also have to be maintained separately, but we could mitigate problems by having notices on both template pages indicating that any changes should be replicated in the other template. Another question-- why shouldn't the vertical template be inserted higher in the page?  LinguistAtLarge • Msg  14:25, 24 January 2009 (UTC)

Do we need this rather intrusive box to begin with? Reader would be better served by some overview article that provides this same list, and maybe a sentence or two on each. Jamming this into random articles on random topics just because they have the word "programming" in them isn't very useful, doesn't improve navigation, doesn't make the main article more readable or understandable. It mostly gets in the way, and is distracting. linas (talk) 14:42, 26 May 2011 (UTC)

Yet another paradigm

Knowledge representation programming should be added. --4th-otaku (talk) 21:38, 6 August 2009 (UTC)

I don't think that's a paradigm per-se. --Cybercobra (talk) 22:55, 6 August 2009 (UTC)

Should stack oriented languages be added to this list? 168.105.238.51 (talk) 00:40, 3 December 2009 (UTC)

Every functional is declarative?

Functional language which is only typed lambda calculi (only "if" construction and no pattern matching) with random access memory operations and unit type can be considered declarative? —Preceding unsigned comment added by 194.85.160.55 (talk) 18:22, 19 December 2009 (UTC)

Automata based programming should not be subordinate to object oriented

Automata based programming should not be subordinate to object oriented, it is not dependent upon OO paradigmken (talk) 04:39, 31 March 2010 (UTC)

Object-oriented does not imply imperative

Please note that object-oriented and imperative are orthogonal properties, so object-oriented should not appear under imperative. There are object-oriented declarative languages such Logtalk, Visual Prolog, CLOS, Needle, CLOVER and FOOPS. pgr94 (talk) 14:53, 22 June 2010 (UTC)

If there are no objections, I will change the template so that object-oriented is a top-level entry. pgr94 (talk) 02:12, 3 July 2010 (UTC)

No-one has voiced any opposition so I have gone ahead and made the change. pgr94 (talk) 00:38, 15 July 2010 (UTC)

Add Literate Programming

Literate programming is certainly its own paradigm and deserves mention. I'm not sure if it belongs under the metaprogramming category or not. 128.101.155.71 (talk) 19:17, 6 April 2011 (UTC)

I think literate programming is a declarative one. Arturotena (talk) 18:25, 9 April 2012 (UTC)

I am not happy with this template

Not that I have time to work on this, but it is a "giant list" of mostly forgotten wannabe paradigms say abductive logic (who uses that now?) and many others. I might jokingly suggest a move to "Yesterday's programming paradigms". I suggest that you guys trim back here, and have show/hide buttons that hide the forgotten items under a "minor paradigms" and have the major paradigms show up first. History2007 (talk) 22:50, 8 February 2012 (UTC)

More problematic is of course this template's underlying assumption that programming "paradigms" form a tree-like structure. —Ruud 22:56, 8 February 2012 (UTC)

Let's start from scratch

I suggest to start from scratch. Please provide sources when making changse. I have provided the source for the 4 main paradigms in the programming paradigm article. Carbo1200 (talk) 18:33, 4 July 2012 (UTC)

Not that I'm attached to the old template, but how is starting from scratch—without a clear idea on how to redesign this template—going to help? —Ruud 19:13, 4 July 2012 (UTC)

It will make it possible to verify sources, and thus confirm relevance and accuracy of new entries. This should not be a shopping list.Carbo1200 (talk) 19:37, 4 July 2012 (UTC)

Carbo1200, I'm clearly in basic agreement with you here (but for AOP, perhaps). Today someone has reverted to the old shopping list - I'll be away and don't want to edit-war: an agreement needs to be worked out with them. Good luck! Chiswick Chap (talk) 09:29, 9 July 2012 (UTC)

For example, I would be tempted to remove aspect-oriented programming from the list (it has just been added) : is it a paradigm, or just a programmimng style / technique ? I would tend to say it's the latter, and should not be in the list (or certainly not at the first level of indentation). But who am I to say ? Instead, we should find a source that says it is a paradigm. Carbo1200 (talk) 19:43, 4 July 2012 (UTC)

Challenges of Aspect-oriented Technology, RT Alexander and James M Bieman, Workshop on Software Quality, Orlando, Florida, 2002. Chiswick Chap (talk) 20:01, 4 July 2012 (UTC)

Another option would be to list the 4 main paradigms and a link to category:programming paradigms. This way, the template has a reasonable size, and still provides navigation to other topics (I'm very hesitant to call them "paradigms" though, but hey). What do you think ? Carbo1200 (talk) 17:23, 19 July 2012 (UTC)

Sidebars are for navigating content. A sidebar that only has four links is pointless. I've reformatted the old content in a more compact manner and stripped out all but the top-level bullets. This is a better skeleton for a rewrite. Chris Cunningham (user:thumperward) (talk) 10:56, 18 August 2012 (UTC)

I'm happier with this format - the old-new one, as you say, contained so little information as to be nearly useless. That said, I'm not convinced collapsing the list of paradigms was a good idea; I miss a few that I would call important, and others seem to be very minor paradigms, buzzwords or not paradigms at all. I would rather start over with a few well-sourced paradigms, but using this template format. 85.226.59.251 (talk) 17:56, 21 August 2012 (UTC)

Feel free to play around with it. This was only a rough attempt at getting the basic layout right for the future: my selection of what to keep was as arbitrary as anyone else's. Chris Cunningham (user:thumperward) (talk) 15:02, 23 August 2012 (UTC)

Procedural

Too newb to add it myself, but Procedural programming is discussed in these here-linked articles as a Programming paradigm, as well as tons in the non-WP web. Seems worth a listing here -- ? "alyosha" (talk) 19:34, 25 August 2012 (UTC)

Unreadable compaction

Hello there, Squiver! Sorry for reverting your compaction attempt, which undoubtedly required a significant amount of time and effort, but it turned the template into an overly compacted and unreadable... thing. If it's unreadable, there's hardly any use of it when displayed. Hope you agree. — Dsimic (talk | contribs) 17:29, 3 February 2015 (UTC)

If the goal is to make the template more compact, we might want to try using {{Collapsible list}} (or some other template, if there's one that suits better) for the branched top-level bullets while keeping the existing overall layout. — Dsimic (talk | contribs) 17:41, 3 February 2015 (UTC)

There's the {{Sidebar with collapsible lists}} one, or maybe the template just has too many sub-bullets of sub-bullets / sub-brackets of sub-brackets? Squiver (talk) 20:35, 3 February 2015 (UTC)

That's awesome, {{Sidebar with collapsible lists}} would fit the bill very well, see the (incomplete and inaccurate) example I've added. Thoughts? — Dsimic (talk | contribs) 21:39, 3 February 2015 (UTC)

Thanks for that. I'm thinking "Should it be left-aligned?", "Should the collapsed sections be grouped together?" and "Should the contrasts have their own section rather than make the headings long?". Squiver (talk) 09:50, 4 February 2015 (UTC)

In a few words – no, no, and no. :) More seriously, centering would kill the structuring by indentation, grouping collapsed sections would make it unreadable, and adding another section for contrasting paradigms would make it much less usable. Though, I'd suggest that we turn those "(contrast: XYZ)" into notes using the {{Efn}} template. Hope you agree. — Dsimic (talk | contribs) 16:00, 4 February 2015 (UTC)

Ok, no centering, grouping or contrasts section, but I've given the prototype here some padding to reduce its left-heavy feel overall and moved the contrasts out of the subheadings. I've also:

• Reduced the number of "contentX="s in use;
• Converted Concurrent computing back into a standard entry as it only had one member (Relativistic programming);
• Given the spreadsheet link (list6) to the "Cell-orientated" text before it, otherwise it'd be the only unlinked text in the lists;
• Made the Modular and Value-level contrasts into footnotes as you suggested, then thought {{efn}} not really necessary?

Hope all that's ok. Squiver (talk) 10:51, 5 February 2015 (UTC)

I amended the footnoting, but perhaps something different would be preferable. Also, maybe the gaps before the collapsed Declarative and Structured sections mean that it might be better to use e.g. a single section/list in a standard Sidebar with Declarative and Structured as {{Collapsible list}}s within?

It does look much better, thanks, but I'd say that we should either stick with having each "top-level leaf" entry as a separate |contentX= in {{Sidebar with collapsible lists}} (as that's how the template is supposed to be used), or go into a complete customization based on {{Collapsible list}}. To me, bunching multiple entries into a single |contentX= defeats the purpose of the {{Sidebar with collapsible lists}} template. Regarding the additional padding on the left, it's fine, but I'd suggest that we keep it in the 0.5–1 em range. Oh, and having notes as part of the template itself, instead of using {{Efn}}, is much better. — Dsimic (talk | contribs) 15:01, 5 February 2015 (UTC)

Thanks for bearing with me as I work out more about what does what etc. I thought what I'd done last time made the template too fiddly (maybe it still is) so I've tried to keep it simple(r) without losing layout while incorporating your points -- except one: the padding. It just looks odd here if the content isn't aligned with the title, so I've retained it (and corrected it slightly). But, if you'd prefer it set differently or removed, go ahead.

I'm glad you thought the footnotes worked -- thanks -- but they were the main thing that seemed fiddly when I saw the template again, so I've put them back in the content but using {{smaller}} and the shorter "compare..." rather than "contrasted with..." text.

There's something else but I can't think what it is now... Hope I haven't gone backwards. Squiver (talk) 19:43, 5 February 2015 (UTC)
PS: Do you know if there's a neater way than (e.g.) "padding-top:0.2em; padding-bottom:0.2em;" to set some top/bottom padding while leaving any left/right padding alone? I was thinking of something like "padding:0.2em inherit;", but that doesn't seem to work (and probably isn't meant to anyway).

Sorry for my delayed response... You're welcome, and thank you for doing all heavy lifting. :) You're right, we also need to keep in mind later maintenance of the template, so its Wiki code should be kept as simple as possible.

Regarding the padding, I'd say that we shouldn't bother with aligining it with the template title – that's anyway highly dependent on the platform and browser that renders it, and pretty much nothing can be expected there. Moving the footnotes back into the template body is fine with me, but how are we going to handle "top-level leaves" that way? I mean, if there are no footnotes, where are we going to put "compare/contrasted" notes for items that do not expand?

Regarding the CSS code needed to set only particular paddings, I've always preferred something like padding-top: 0.2em; padding-bottom: 0.2em; as it's highly readable and easily maintainable. — Dsimic (talk | contribs) 13:21, 9 February 2015 (UTC)

By the way, we might also want to see how {{OSIModel}} template does a similar thing. — Dsimic (talk | contribs) 06:31, 11 February 2015 (UTC)

Hey, Ruud Koot! As noted in my revert, I apologize for reverting your edit, which was good as the need for compaction is obvious, but the new layout example present here is quite incomplete (it serves only as a working example), causing us a loss of many paradigm (sub)types when pushed live as such. We just need to revisit the whole thing a bit, iron out any remaining formatting/alignment issues, complete the refactoring, and push the changes live. Perhaps Squiver would also like to participate? — Dsimic (talk | contribs) 04:40, 22 August 2015 (UTC)

Hmm.... I'm beginning to have even more doubts about this template, now you mention "completeness".

If you want this template to be "complete" (that is, list all articles in Category:Programming paradigms), then it should be converted to a navbox instead. Having these "sidebar navigation boxes" is only acceptable if they are kept very short. That can in this case only be achieved by making it incomplete. The collapsing trick is also not going to work for an indirect reason: programming paradigms can't really be ordered in a non-arbitrary tree structure if you want it to be very inclusive (well, or a tree that is going very wide at the root, which defeats the purpose).

See the horror that is now happening at Recursion (computer science). —Ruud 10:44, 22 August 2015 (UTC)

I've referred to "completeness" in the sense of including all articles that describe programming paradigms; IMHO, we should be happy to have so many such articles. :) Quite frankly, I'd just turn the sidebar into a collapsed form for now, which would surely be an improvement, and see what else to do later. Oh, and Recursion (computer science) does look stretched. :) — Dsimic (talk | contribs) 17:55, 22 August 2015 (UTC)

What about Return oriented programming?

Hello,

I think this paradigm is missing: https://wiki.riteme.site/wiki/Return-oriented_programming

Regards Julien — Preceding unsigned comment added by 141.35.40.184 (talk) 12:39, 28 November 2016 (UTC)

It's a computer security exploit, so it probably cannot be classified as a programming paradigm. Jarble (talk) 20:21, 20 September 2017 (UTC)

Procedural not under Structured

procedural programming starts with "Procedural programming is a programming paradigm, derived from structured programming", but here procedural is under imperative. Shouldn't it be under structured? Orenmn (talk) 15:18, 26 October 2017 (UTC)

Some of these are more important than others

Would suggest a re-think of how this is presented to emphasise the important paradigms and types.--86.12.160.194 (talk) 11:48, 17 July 2018 (UTC)

removed Natural Language Programming

I removed the entry Natural Language Programming as it is not a paradigm as far as I am aware. If someone wants to keep it, please provide some sources to establish notability. It was in Pulido-Prieto, O. and Juárez-Martínez, U., 2017. A survey of naturalistic programming technologies. ACM Computing Surveys (CSUR), 50(5), p.70. Test written in natural language as in behavior-driven development as definitely a thing. What is the inclusion criteria for this template? Notgain (talk) 03:50, 13 July 2019 (UTC)

added query language as sub of declarative

Having browsed all the above comments, I appreciate there are multiple issues with this template, but I don't have any great ideas on how to rebuild it from scratch. As a DBA I was looking for where SQL would fit and surprised to not find it under Declaratives, so I checked the SQL page and it refers back to the Query language page, which itself declares itself to be part of the Declarative paradigm, so it seemed a consistency fix. Although the Query language page could use some work. Helvetius (talk) 11:56, 3 January 2022 (UTC)

too long

this template is way too long. It'd be better converted from a vertical sidebar to a horizontal navbox. fgnievinski (talk) 05:59, 22 July 2023 (UTC)

@Fgnievinski: I completely agree. There has been plenty of discussion in the past on how to improve the sidebar, but nothing seems to have come of it. Reworking it into a navbox instead seems much preferable, as it can then stay reasonably comprehensive without overwhelming the articles it is used on. Felix QW (talk) 13:58, 25 October 2023 (UTC)

@Fgnievinski @Felix QW Well the big-list style really bothered me so I made a navbox version in the sandbox. There are some small inconsistencies that I did for organization's sake:

• Modular programming states it is a sibling of structured programming, not a child of it, but I put it as a child anyway
• OOP is arguably not imperative programming? I don't know of any non-imperative OOP languages though
• I put dataflow etc. under functional because of FRP, but maybe they should be a separate row
• I put ontology and query languages under logic. Ontology makes sense, the page mentions first order logic several times, but for query language I am less sure - e.g. Datalog can be used to query databases, but calling SQL a logic programming language is a bit of a stretch.
• Similarly constraint programming is closely associated with logic (e.g. you can do it in Prolog), but it is not quite a parent-child relationship
• DSLs: this whole categorization of array languages, set languages, etc. as DSLs is a bit subjective. I don't know where else these things fit though. Certainly it is true that they are languages / programming styles specialized for a specific domain. Except maybe for NLP, but there the only example is Inform 7 which I think is indeed a DSL (for writing text adventure games). Also stacks, arguably that would go better near concatenative.
• Separation of concerns: IDK, things like data-driven programming don't fit anywhere else and the article mentioned aspects so I said, why not make a row for aspect-like things? If you squint you can sort of see how all of the paradigms are imposing a structure on the program that separates concerns.

Overall I think it is in a decent state. Do you think it is good enough to use? Mathnerd314159 (talk) 03:53, 25 January 2024 (UTC)

Well it has been a bit so I went ahead and changed it on a subset of the pages. If there are no complaints I will finish it up tomorrow. Mathnerd314159 (talk) 00:57, 1 February 2024 (UTC)

Thank you very much for your efforts, and my apologies for not replying earlier. While one can certainly discuss the individual items you mentioned above, I think that the navbox is already a major improvement over the unwieldy sidebar. So from my point of view, please go ahead with the roll-out! Felix QW (talk) 07:49, 1 February 2024 (UTC)

Alright, it is done, no more main-space transclusions listed [1]. I have marked this template as deprecated. Mathnerd314159 (talk) 23:47, 1 February 2024 (UTC)