Talk:Programming language: Difference between revisions

Revision as of 04:37, 27 January 2024

Revision as of 04:57, 27 January 2024

Line 193:

{{talk ref}}

Thanks [[User:Buidhe paid|Buidhe paid]] ([[User talk:Buidhe paid|talk]]) 02:23, 25 January 2024 (UTC)

Please replace the current content of the "Design and implementation" section, after the hatnote, with the following ("specification" subsection is unchanged):

{{collapse top}}

One of the most important influences on programming language design has been [[computer architecture]]. [[Imperative languages]], the most commonly used type, were designed to perform well on [[von Neumann architecture]], the most common computer architecture.{{sfn|Sebesta|2012|p=18}} In von Neumann architecture, the [[Computer memory|memory]] stores both data and instructions, while the [[CPU]] that performs instructions on data is separate, and data must be piped back and forth to the CPU. The central elements in these languages are variables, [[Assignment (computer science)|assignment]], and [[iteration]], which is more efficient than [[Recursion (computer science)|recursion]] on these machines.{{sfn|Sebesta|2012|p=19}}

Many programming languages have been designed from scratch, altered to meet new needs, and combined with other languages. Many have eventually fallen into disuse.{{cn}} The birth of programming languages in the 1950s was stimulated by the desire to make a universal programming language suitable for all machines and uses, avoiding the need to write code for different computers.{{sfn|Nofre|Priestley|Alberts|2014|p=55}} By the early 1960s, the idea of a universal language was rejected due to the differing requirements of the variety of purposes for which code was written.{{sfn|Nofre|Priestley|Alberts|2014|p=60}}

===Tradeoffs===

Desirable qualities of programming languages include readability, writability, and reliability.{{sfn|Sebesta|2012|p=8}} These features can reduce the cost of training programmers in a language, the amount of time needed to write and maintain programs in the language, the cost of compiling the code, and increase runtime performance.{{sfn|Sebesta|2012|pp=16–17}}

*Although early programming languages often prioritized efficiency over readability, the latter has grown in importance since the 1970s. Having multiple operations to achieve the same result can be detrimental to readability, as is [[operator overload|overloading operators]], so that the same operator can have multiple meanings.{{sfn|Sebesta|2012|pp=8–9}} Another feature important to readability is [[orthogonality]], limiting the number of constructs that a programmer has to learn.{{sfn|Sebesta|2012|pp=9–10}} A syntax structure that is easily understood and [[reserved word|special word]]s that are immediately obvious also supports readability.{{sfn|Sebesta|2012|pp=12–13}}

*Writability is the ease of use for writing code to solve the desired problem. Along with the same features essential for readability,{{sfn|Sebesta|2012|p=13}} [[abstraction (computer science)|abstraction]]—interfaces that enable hiding details from the client—and [[Expressive power (computer science)|expressivity]]—enabling more concise programs—additionally help the programmer write code.{{sfn|Sebesta|2012|pp=14–15}} The earliest programming languages were tied very closely to the underlying hardware of the computer, but over time support for abstraction has increased, allowing programmers express ideas that are more remote from simple translation into underlying hardware instructions. Because programmers are less tied to the complexity of the computer, their programs can do more computing with less effort from the programmer.<ref>Frederick P. Brooks, Jr.: ''The Mythical Man-Month'', Addison-Wesley, 1982, pp. 93–94</ref>

*Reliability means that a program performs as specified in a wide range of circumstances.{{sfn|Sebesta|2012|p=15}} [[Type checking]], [[exception handling]], and restricted [[aliasing (computing)|aliasing]] (multiple variable names accessing the same region of memory) all can improve a program's reliability.{{sfn|Sebesta|2012|pp=8, 16}}

Programming language design often involves tradeoffs.{{sfn|Sebesta|2012|pp=18, 23}} For example, features to improve reliability typically come at the cost of performance.{{sfn|Sebesta|2012|p=23}} Increased expressivity due to a large number of operators makes writing code easier but comes at the cost of readability.{{sfn|Sebesta|2012|p=23}}

{{anchor|English-like programming languages}}

[[Natural-language programming]] has been proposed as a way to eliminate the need for a specialized language for programming. However, this goal remains distant and its benefits are open to debate. [[Edsger W. Dijkstra]] took the position that the use of a formal language is essential to prevent the introduction of meaningless constructs.<ref>Dijkstra, Edsger W. [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html On the foolishness of "natural language programming."] {{webarchive|url=https://web.archive.org/web/20080120201526/http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html |date=20 January 2008 }} EWD667.</ref> [[Alan Perlis]] was similarly dismissive of the idea.<ref>{{cite web|last=Perlis|first=Alan|url=http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html|title=Epigrams on Programming|work=SIGPLAN Notices Vol. 17, No. 9|date=September 1982|pages=7–13|url-status=live|archive-url=https://web.archive.org/web/19990117034445/http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html|archive-date=17 January 1999}}</ref>

===Specification===

{{Main|Programming language specification}}

The specification of a programming language is an artifact that the language [[programmer|users]] and the [[programming language implementation|implementors]] can use to agree upon whether a piece of [[source code]] is a valid [[computer program|program]] in that language, and if so what its behavior shall be.

A programming language specification can take several forms, including the following:

* An explicit definition of the syntax, static semantics, and execution semantics of the language. While syntax is commonly specified using a formal grammar, semantic definitions may be written in [[natural language]] (e.g., as in the [[C (programming language)|C language]]), or a [[formal semantics of programming languages|formal semantics]] (e.g., as in [[Standard ML]]<ref>{{cite book|last=Milner|first=R.|author-link=Robin Milner |author2=[[Mads Tofte|M. Tofte]] |author3=[[Robert Harper (computer scientist)|R. Harper]] |author4=D. MacQueen |title=The Definition of Standard ML (Revised)|publisher=MIT Press|year=1997|isbn=978-0-262-63181-5}}</ref> and [[Scheme (programming language)|Scheme]]<ref>{{cite web|first=Richard|last=Kelsey|author2=William Clinger|author3=Jonathan Rees|title=Section 7.2 Formal semantics|work=Revised⁵ Report on the Algorithmic Language Scheme|url=http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.2|date=February 1998|url-status=live|archive-url=https://web.archive.org/web/20060706081110/http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.2|archive-date=6 July 2006}}</ref> specifications).

* A description of the behavior of a [[compiler|translator]] for the language (e.g., the [[C++]] and [[Fortran]] specifications). The syntax and semantics of the language have to be inferred from this description, which may be written in natural or formal language.

* A [[reference implementation|''reference'' or ''model'' implementation]], sometimes [[Meta-circular evaluator|written in the language being specified]] (e.g., [[Prolog]] or [[REXX|ANSI REXX]]<ref>[[American National Standards Institute|ANSI]] – Programming Language Rexx, X3-274.1996</ref>). The syntax and semantics of the language are explicit in the behavior of the reference implementation.

===Implementation===

{{Main|Programming language implementation}}

An implementation of a programming language is the conversion of a program into [[machine code]] that can be executed by the hardware. The machine code then can be executed with the help of the [[operating system]].{{sfn|Sebesta|2012|pp=23–24}} The most common form of interpretation in [[Software release life cycle|production code]] is by a [[compiler]], which translates the source code via an intermediate-level language into machine code, known as an [[executable]]. Once the program is compiled, it will run more quickly than with other implementation methods.{{sfn|Sebesta|2012|pp=25–27}} Some compilers are able to provide further [[optimization]] to reduce memory or computation usage when the executable runs, but increasing compilation time.{{sfn|Sebesta|2012|p=27}}

Another implementation method is to run the program with an [[interpreter]], which translates each line of software into machine code just before it executes. Although it can make debugging easier, the downside of interpretation is that it runs 10 to 100 times slower than a compiled executable.{{sfn|Sebesta|2012|p=28}} Hybrid interpretation methods provide some of the benefits of compilation and some of the benefits of interpretation via partial compilation. One form this takes is [[just-in-time compilation]], in which the software is compiled ahead of time into an intermediate language, and then into machine code immediately before execution.{{sfn|Sebesta|2012|pp=29–30}}

{{talk ref}}

{{collapse bottom}}

Please add the following source to the "further reading" section:

*{{cite journal |last1=Nofre |first1=David |last2=Priestley |first2=Mark |last3=Alberts |first3=Gerard |title=When Technology Became Language: The Origins of the Linguistic Conception of Computer Programming, 1950–1960 |journal=Technology and Culture |date=2014 |volume=55 |issue=1 |pages=40–75 |url=https://www.jstor.org/stable/24468397 |issn=0040-165X}}

Thank you [[User:Buidhe paid|Buidhe paid]] ([[User talk:Buidhe paid|talk]]) 04:37, 27 January 2024 (UTC)