Template talk:Infobox programming language

Similar/Alternative languages

I think there should be a "Similar/alternative languages" item in this infobox. How do I make that happen? -Barry- 03:57, 29 April 2006 (UTC)

Someone in IRC just told me I should edit this page. If that's all that's needed to use the added item in another article, it should be mentioned that this article isn't just documentation on how to use the infobox. It actually allows you to change how the template works in the article. -Barry- 04:14, 29 April 2006 (UTC)

Didn't work. Still need to know how to change the template. -Barry- 04:24, 29 April 2006 (UTC)

Turing complete?

Is the "Turing complete" item really necessary? As the article on Turing completeness says, "Most programming languages, conventional and unconventional, are Turing-complete ... It is difficult to find examples of non-Turing complete languages". Are there any languages that have articles where the value of this item would be "no"? If not, isn't it somewhat superfluous? Oli Filth^{(talk|contribs)} 08:36, 5 August 2008 (UTC)

Can we please lose the "turing complete" thing, per Oli Filth?! It's a silly and unnecessary distraction. The vast majority of PLs are Turing complete. It's definitely noteworthy in the articles of those few that are not, but Charity (programming language) or SQL-92 can note that fact in their leads. We don't use fields for topics where 99% of the uses share a value (let alone for a boolean value).... it would be like adding a field for "Text based": there are a few PLs that use icons rather than text, but not enough to change the box. Or probably even "Non-English keywords" is sufficiently rare not to get a field, as another example. LotLE×talk 21:05, 5 August 2008 (UTC)

'hello world' addition

Scheme

Paradigm	functional

You know, I've noticed that most programming language articles include the basic 'hello world' construction for that language. it strikes me as a bit silly to have a separate section for that in these articles, and I'm thinking we should move them into the infobox. I'll add a parameter and post an example here, so you can see the effect. --Ludwigs2 16:54, 20 June 2010 (UTC)

Example added at right. --Ludwigs2 17:31, 20 June 2010 (UTC)

(A) Some Hello Worlds are so verbose they would bloat the infobox (I'm looking at you, Java!) (B) The Hello Worlds are often accompanied by explanatory prose, thus this field will either duplicate the code or will cause the example and its prose to become separated. --Cybercobra (talk) 00:44, 21 June 2010 (UTC)

Hello World examples are rarely this compact, and don't really fit the at-a-glance nature of infobox templates. There's nothing wrong with them being article boilerplate; the infobox doesn't need to cover everything that the article does. Conversely, the examples certainly should not be moved to the infobox, as infoboxes are only meant to be summaries and articles should stand alone fine without them. Chris Cunningham (not at work) - talk 11:43, 22 June 2010 (UTC)

"Programming language" label in a "programming language" infobox?

I assume this field is supposed to described the language used to implement another language, and not a field in which to put the name of the language being described. I changed the label of this field to "Implementation langauge" but left the field's name in the template the same. 75.186.5.185 (talk) 03:52, 8 December 2010 (UTC)

That filed doesn't make sense to me. A programming language doesn't have any implementation language, because it can (and usually does) have multiple implementations, written in various languages. Do you think this field makes sense or should it be removed? Svick (talk) 21:41, 8 December 2010 (UTC)

I personally think it's better to remove it and leave any descriptions of implementation languages in the article body. When you have multiple implementations with different languages used to implement each (think CPython vs Jython vs IronPython for example) trying to convey this in an infobox field would just look messy. Additionally, where I've seen the field already used -- in the entries for Rust, Scala, Haxe and OCaml -- the information provided is wrong anyway! Thanks. Hexene (talk) 18:20, 27 August 2013 (UTC)

TOBIE rank

I'd like to add TIOBE rank as one field of this template as I often find figures with // of a company infobox quite informative. Here are the top 20 languages:

1. C
2. Java
3. Objective-C
4. C++
5. C#
6. PHP
7. (Visual) Basic
8. Python
9. Perl
10. Ruby
11. JavaScript
12. Delphi/Object Pascal
13. Lisp
14. Pascal
15. Visual Basic .NET
16. Ada
17. MATLAB
18. Lua
19. Assembly
20. PL/SQL

I know that this might be as controversial as the use of Alexa rank in a website infobox, but I'd like to go ahead in a month or two unless there is a Oppose here. — Kennyluck (talk) 07:18, 2 January 2013 (UTC)

Year

Is there a definition of what is meant by the 'year' field? For example, Rust began as a single-person effort in 2006, had an official unveiling and public mailing list created in 2010, and made its first numbered release (0.1) in 2012, so which should it use? Thanks! Hexene (talk) 14:14, 22 June 2013 (UTC)

Template needs updating

Hi please remove label 12 and data 12 and merge them into data 11 please because test version and preview version are the same and please do some update to the stable release and preview release to reflect on a template change at template:LSR and template:LPR please. 86.135.252.13 (talk) 20:11, 25 March 2014 (UTC)

Not done: Hi. Are you sure you know what you are talking about? Best regards, Codename Lisa (talk) 01:59, 26 March 2014 (UTC)

hi yes because you have dublicate labels they both say preview release but on the data bit one says preview and the other says test. 86.135.252.13 (talk) 07:29, 26 March 2014 (UTC)

Look, when someone says "Are you sure you know what you are talking about?" he or she means "I cannot locate or verify what you are referring to. Please elucidate with line number, sample snippets of the code, etc." Label 12 is "Influenced by". Label 11 is "Dialects". Label 7 is "Preview release" which accepts its value through |latest preview version= and its aliases |latest test version=, |latest_preview_version= and |latest_test_version=. (Sorted by the order of precedence.)

Best regards,

Codename Lisa (talk) 22:26, 26 March 2014 (UTC)

Spacing

Can we come up with a way to add spacing around the logo/caption in C (programming language) without using hacks like multiple br tags? seems like if the spacing is that useful, we should add it to the infobox directly. Frietjes (talk) 14:04, 30 April 2014 (UTC)

Changing "appeared in" to "initial release"

Would there be any opposition to this? I ask because this phrasing is awkward when the exact date of release is known Sizeofint (talk) 03:27, 8 April 2015 (UTC)

Hi. Sometimes, this infobox is put an article about a language, not an IDE. So, there would be no initial release at all.

Best regards,

Codename Lisa (talk) 10:38, 8 April 2015 (UTC)

Thanks for responding. I'm really referring to OpenCL rather than any IDE. Wouldn't there have to be a date when the language was made public/widely available? I would think that even for a language like B it would make as much sense to say "initial release: 1969" as to say "appeared in: 1969". Sizeofint (talk) 16:57, 8 April 2015 (UTC)

I am not sure. "Languages" aren't "released". These two words don't collocate. Programming languages appear, are implemented and are adopted. And since at least I don't think "appeared in" is wrong, on the whole I think the change you suggest is somewhat of a downgrade. Best regards, Codename Lisa (talk) 09:22, 9 April 2015 (UTC)

Hmm... I guess I understand your reasoning. What about just dropping the "in" so the infobox will have "Appeared" and then a date? That would allow use of specific days without sounding awkward. Regards Sizeofint (talk) 19:53, 9 April 2015 (UTC)

You might be on to something there. We usually write "it appeared on 19 August 2019", "it appeared in August 2019", "it appeared in 2009", "it appeared in 2010s" but still I expect a lot of infoboxes would report day too. Or do they...? Maybe "first appearance"?

I don't know.

Best regards,

Codename Lisa (talk) 20:44, 9 April 2015 (UTC)

"First appearance" or "First appeared" sound pretty good to me. Most languages don't include the exact day at this point but that might be an effect of the current wording. I know for at least Go and OpenCL C the exact date is available. Sizeofint (talk) 20:56, 9 April 2015 (UTC)

|latest test version= and |latest test date= aliases no longer work

Ping @Codename Lisa: and @Waldir:, who else? I found the issue at Special:Diff/742033177. 80.221.159.67 (talk) 07:48, 1 October 2016 (UTC)

Thanks for the notice. The issue seems to have been introduced in Special:Diff/736291678, so I'll let Codename Lisa handle it. --Waldir ^talk 12:50, 1 October 2016 (UTC)

 Done Call me any time if you had more problems. —Best regards, Codename Lisa (talk) 13:41, 1 October 2016 (UTC)

Examples of scope

What's the purpose of scope? It will be useful to have some concrete examples. It's not very clear from the definition given. — Preceding unsigned comment added by Jsamwrites (talk • contribs) 11:49, 23 March 2017 (UTC)

Memory Management (04/2017)

A field for memory management usage type will be useful: garbage collector, counting references ...(04/2017) — Preceding unsigned comment added by 111.184.74.184 (talk • contribs)

 Done NM 00:58, 14 September 2023 (UTC)

Package managers

How about adding a parameter for specifying the package managers (official and unoffical) of the langauge? Galzigler (talk) 14:31, 27 May 2017 (UTC)

• Oppose. It is fancruft. —Codename Lisa (talk) 14:46, 27 May 2017 (UTC)

Introduced Constructs

I think it would be useful to add an optional introduced_constructs section to the infobox. For example,

“ Simula 67 introduced objects,[1]:2, 5.3 classes,[1]:1.3.3, 2 inheritance and subclasses,[1]:2.2.1 virtual procedures,[1]:2.2.3 coroutines,[1]:9.2 and discrete event simulation,[1]:14.2 and features garbage collection.[1]:9.1 ”

appears in the article on Simula. It seems to me that this information would be both useful and compact enough to fit in the infobox.

Bhbuehler (talk) 03:57, 14 January 2019 (UTC)

Semi-protected edit request on 2 August 2021

I think we could add a |country_of_origin or |origin field to show where the language was developed. We already tell who developed or created it but not where they are from. We also show the country of origin of a lot of products and productions in other templates, so knowing where a programming language comes from might be relevant. 200.242.43.202 (talk) 15:21, 2 August 2021 (UTC) 200.242.43.202 (talk) 15:21, 2 August 2021 (UTC)

 Not done: I don't think that's information that would really ever be relevant for the infobox of a programming language. For a random example, the fact that Guido van Rossum is Dutch isn't even mentioned in the prose of Python (programming language). It could plausibly be mentioned in the history section, but a factoid like that I don't think is relevant enough for an infobox. Maybe others will disagree with me though. ‑‑Volteer1 (talk) 15:29, 2 August 2021 (UTC)

@Volteer1: personally I think it's relevant to know where it came from or where it was developed because that can explain the context of why they decided to create a certain language or what kind of contribution they wanted to make to that environment. For example, the Ada programming language was created for military purposes by a team hired by the US Department of Defense (Lua is also an example of a language created from a locally sourced need). However, I don't know if my argument is good enough to justify adding the field I proposed. 200.242.43.202 (talk) 17:15, 2 August 2021 (UTC)

Those two example are interesting, I do admit. Personally I still don't think there's really a use case for it, but if anyone else disagrees with me feel free to add it in. ‑‑Volteer1 (talk) 06:03, 4 August 2021 (UTC)

Change Screenshot to SampleCode

Hi, Screenshot for programming language Infobox is not true. We should use SampleCode and insert some code like "print Hello World" in it. So in my opinion image2 in this template should not be jpg, svg, or other solid images, inversely it should be a textbox that has a white background and its text has copying capability and its syntax (types) has some appropriate highlighting, which is successfully provided by a <syntaxhighlight></syntaxhighlight> tag. So this image

in an Infobox is wrong and should be some thing like:

JavaScript

Paradigm	Multi-paradigm: event-driven, functional, imperative, object-oriented programming
Designed by	Brendan Eich of Netscape initially; others have also contributed to the ECMAScript standard
First appeared	December 4, 1995 (1995-12-04)
Typing discipline	Dynamic, weak, duck
Filename extensions	.js .cjs .mjs
Website	www.ecma-international.org/publications-and-standards/standards/ecma-262/
Major implementations
V8, JavaScriptCore, SpiderMonkey, Chakra
Influenced by
Java, Scheme, Self, AWK, HyperTalk
Influenced
ActionScript, AssemblyScript, CoffeeScript, Dart, Haxe, JS++, Objective-J, Opa, TypeScript
JavaScript at Wikibooks

Thanks, Hooman Mallahzadeh (talk) 08:15, 3 February 2022 (UTC)

A section on this talk page discusses why sample code in the infobox isn't a good idea: some examples are quite verbose and would bloat the infobox; sample code sections typically have explanatory text which would be left out of the infobox to avoid further bloat, which would lead to the sample code either being duplicated or separated from its explanation; infoboxes are intended to be an "at-a-glance" source of information, they should summarize key facts (MOS:INFOBOXPURPOSE), which isn't what sample code does. Most programming language articles have a section with examples of code, which is where it makes sense for examples to be.

The Javascript article's screenshot of code in the infobox, rather than a logo, is an unusual case because (as I understand it) Javascript has no official logo; it isn't there as an example of how the language works, it's just an image to represent the language in this case where there's no logo to do so. AKiwiDeerPin (talk) 09:11, 28 July 2022 (UTC)

@AKiwiDeerPin Hi, in my opinion screenshot should be gradually removed from all programming language Infoboxes, so we should mark "screenshot" and "screenshot caption" as a deprecate parameters. Do you agree? Hooman Mallahzadeh (talk) 09:39, 28 July 2022 (UTC)

As of the beginning of July, the screenshot parameter was in use on almost 50 different pages (a list here), so I would say no, it seems to be considered useful by the people who have worked on those pages for a variety of reasons. Some languages would be difficult or impossible to represent in standard characters - Logo, for example, communicates some very basic ideas about how the language works in an image, while Scratch and similar visual programming languages work in ways that are best communicated via a screenshot of the interface. On other pages they just show what the language or a program looks like, and I don't have any problem with those uses either.

Why do you think screenshots should be removed from all programming language infoboxes? You haven't actually made an argument for doing so. AKiwiDeerPin (talk) 10:29, 28 July 2022 (UTC)

@AKiwiDeerPin Because a language is a collection of words that follow some syntax and have semantics and produces some machine code. Here, screenshot is totally an unrelevant argument. Making screenshot for a collection of words is meaningless, and we should show that words exactly in sampleCode. Some Infoboxes of Wikidedia use screenshot for IDE of that language. This is not true. IDE is a totally different concept from language. For the Logo language, wrong screenshot is used. Here an algorithm is shown, not the language. Algorithm should not be shown in Infobox, but outside of the Infobox, we can use that image. As a conclusion, I really insist to deprecate screenshot parameter, and in the emergency cases only use sampleCode parameter. In all of 50 pages, we should put used screenshot image outside of Infobox, because it either shows IDE, or shows an algorithm, not exactly that language (i.e., a collection of words). Specially in JavaScript page that a black page is shown and words is not readable and I really think this would make that Infobox bloating. Hooman Mallahzadeh (talk) 11:20, 28 July 2022 (UTC)

The screenshot of Scratch shows Scratch, as it is actually used. Why remove it? Screenshots of IDEs show examples of languages being used, which is the best you can do in an infobox since they are not the place for in depth information. Because yes, languages have syntax and semantics, but the infobox isn't the place to explain any of that. I don't know how you expect to represent "exactly that language", and not "a collection of words", in an infobox. It seems contrary to the purpose of an infobox. Pretty much no programming language could be fully represented even in an entire Wikipedia article, nevermind just an infobox.

I still don't know what your objection to the screenshots actually is. You've said they're "not true" a couple of times now, and that doesn't make any sense to me, they're not lying about the language represented.

As I mentioned, I think the JavaScript page seems to have sort of ended up with an example of JavaScript in use instead of a logo. A logo also would not explain the syntax and semantics of a language. It would just represent that language. In an infobox, a screenshot of a language in use shows just one of infinite ways that language is used, and is in the infobox to represent that language or give an example of it.

The infobox for the article about Japanese has just one word, and just one way that word could be written, as the image in its infobox. It's not a full sentence. It's not a dictionary definition. It's not an example of the syntax and semantics of the language. It's just a picture that is there as an example of (part of) the subject of the article.

The infobox for the article about apples has a picture of one type of apple; it isn't claiming this is what every apple is like or this is all there is to know about apples, it's just one picture of an apple as an example in order to illustrate the subject of the article.

AKiwiDeerPin (talk) 12:54, 28 July 2022 (UTC)

@AKiwiDeerPin One of the main disadvantages of this parameter is that screenshot image is too small such that it conveys very low and not enough data "At the first glance" to a user. At the first glance screenshot of JavaScript shows nothing, and we should open that picture to view what it contians. Again for Scratch (programming language) the screenshot image is too small such that at the first glance we understand nearly nothing from that image, again we should open that image to understand what it contains. The problem promotes when it is selected as PageImage of article, a nearly totally black image is shown in tooltip for JavaScript. Hooman Mallahzadeh (talk) 13:50, 28 July 2022 (UTC)

Shell scripting

Thank you for making this infobox. I've enjoyed navigating the "influenced" and "influenced by" crosslinks to understand the origins of computer languages.

I want to ask for advice. The languages I've found so far under shell script such as Bourne Shell, Bash, Zsh, etc. currently have the Template:Infobox software. These languages have influenced and were influenced by languages that use the Template:Infobox_programming_language.

I'm guessing the reason why the shell scripts don't have this infobox, is because the words are simultaneously used for the software and for the computer language.

Would you think it would be proper to move these pages to use Template:Infobox_programming_language instead? Or, would it make more sense maybe to try to extend Template:Infobox software to use the fields "influenced" and "influenced by"? What are your thoughts here? 'wɪnd (talk) 08:14, 7 September 2022 (UTC)

Media-type and UTI fields

JavaScript has a media type and UTI respectively defined as text/javascript and com.netscape.javascript-source. Similarly, XUL is XML-based, but has a distinct media-type of application/vnd.mozilla.xul+xml. These properties are supported {{Infobox file format}}, but not by this template. I recommend establishing parity between the two by supporting the same type-related fields:

{{Infobox programming language
| _nomimecode =
| mime =
| type_code =
| uniform_type =
| conforms_to =
}}

Thoughts? — Alhadis (talk) 09:31, 9 October 2024 (UTC)