Talk:Programming language/Archive 2

From Wikipedia, the free encyclopedia

Contents

[edit] HTML and Turing-completeness

Derek farn (talk • contribs) recently reverted the article from this:

Some examples of languages that are not Turing complete are HTML (although it can contain Turing complete languages such as PHP and Javascript)

back to this:

Some examples of languages that are not Turing complete are pure HTML (the use of embedded PHP or Javascript makes it Turing complete)

reasoning that "HTML with embedded PHP is still HTML; the two interact within a web page".

I disagree with this sentiment, hence my original edit. My reasoning is:

  • HTML with embedded PHP is not still valid HTML. (Try running PHP files through an HTML validator.)
I used the phrase "pure HTML" to imply HTML without extensions. But then of course <script> ... </script> is in this pure HTML and it can contain Javascript. Not an ideal solution, but I think it conveys the intent in a few words. Derek farn 00:02, 14 May 2006 (UTC)
  • PHP does not know, or care, what kind of data you put in its raw output sections. (It can be HTML, CSS, XML, ASCII art, or anything else conceivable.)
I don't see what this has to do with this issue. Derek farn 00:02, 14 May 2006 (UTC)
  • PHP and Javascript don't "interact" with HTML; they interact with the browser/user agent and the DOM tree. HTML's role is nothing more than a completely passive data format. (The same role can be filled by other formats, like XUL, for example.)
The two do 'interact' within a web page to produce a desired result. What it is that they each interact with is too low level a detail to get involved with here. Derek farn 00:02, 14 May 2006 (UTC)
  • In other words, embedding PHP/Javascript in HTML does not make HTML Turing-complete any more than putting a computer on a table makes the table Turing-complete. The two are simply orthogonal, and i think it confuses the issue to suggest otherwise.
A great many web developers (or at least the ones I seem to talk too) seem to make little distinction between HTML with/without some embedded scripting language. I added the PHP/Javascript wording to head off heated debates about what is/is not HTML. Derek farn 00:02, 14 May 2006 (UTC)
I always read that HTML with scripting (client or server side) was called Dynamic HTML (DHTML). The script tag hasn't always existed.Jaxad0127 01:43, 14 May 2006 (UTC)
Good observation. The HTML article does not mention static but there is a dynamic HTML article. This is the distinction we need to make (I'm assuming that all scripting languages are Turing complete???). Derek farn 12:19, 14 May 2006 (UTC)
This is where Turing completeness gets a little sticky.
Very sticky in that we have to make a distinction between algorithms and 'real world' output. Turing completeness deals with algorithms and does not get involved with setting bit that cause lights to come on, or some other user visible behavior). So yes, there are languages where it is possible to write programs that cause things to happen that cannot be written in another language (because the compiler for that language does not provide a mechanism, or the compiler for the language might not even exist on a given problem). So the wording really ought to talk about 'algorithms being expressed'; the current wording takes the simplistic approach. Derek farn 16:11, 13 June 2006 (UTC)
While you can generally do the same thing in all languages, some have special constructs that cannot be simulated in other scripting languages without extending (rewriting) the interpreter. With HTML in mind, a good example is JavaScript (JScript) vs. VBScript. JavaScript can easily change things like class and style, while all VBSCript can do is replace the tag entirely, which never works. But, VBScript has a special construct just for HTML pages (I can't remember what it is or find the book describing it) that allows it to turn the document into a word processor, the exact nature of which is nearly impossible to do in JavaScript, given it's limitations. But for the most part, they can be used interchangeably. Jaxad0127 15:41, 13 June 2006 (UTC)

Would anyone else care to share their opinion, and help settle this? --Piet Delport 11:35, 13 May 2006 (UTC)

[edit] strong typing vs. weak typing in Scheme and Lisp

In the table, Lisp is listed as strong while Scheme is listed as weak. At a minimum it would seem to me that the two should be the same. Within Wikipedia Lisp and Common Lisp are listed as dynamically typed, without mention of strong or weak typing. Discussion on the scheme programming language page leans towards calling it strong, although it acknowledges that usages in the literature differ.

I think we should try to establish a consistent usage within Wikipedia at least, preferably backed up by references. Can anyone help with this? Ideogram 14:00, 31 May 2006 (UTC)

[edit] prepare for major changes

I intend to merge content from User:K.lee's infamously delayed rewrite into this article. This will entail major changes. If you have any opinions or suggestions, especially related to k.lee's rewrite, now is the time to discuss them. Ideogram 04:02, 1 June 2006 (UTC)

I have created the subpage Talk:programming language/merge so that we can work on this without disturbing the current article. Ideogram 04:48, 1 June 2006 (UTC)

I have merged the History section. Ideogram 05:08, 1 June 2006 (UTC)

I have merged the Taxonomies section. Ideogram 05:26, 1 June 2006 (UTC)

Ok since no one has spoken up, it must be ok to commit my changes to the current article. I have done so. Let's see if that stirs things up. Ideogram 23:38, 2 June 2006 (UTC)

I have merged the Why programming languages? section. I will wait a little while before committing it to the current article. Ideogram 17:09, 3 June 2006 (UTC)

I have committed this change to the current article. Ideogram 06:21, 4 June 2006 (UTC)

I have completed the merge, primarily involving merging the Elements section. Again I will wait a little while before committing the changes. Ideogram 06:54, 4 June 2006 (UTC)

I'm not fully sure what the status is on everything, so if what I say isn't relevant, I apologize. In both the current and the merge articles, the "Type system" section refers to a main article. In both articles, the text that follows seems far too long. Since we're referring to a main article, the text that follows should only give a very cursory overview of the subject. Compare to the "Data structures" section in either article, which is of a much more appropriate length, I think. – Zawersh 07:58, 4 June 2006 (UTC)
Yes, it is quite long but it is broken up into subsections static/dynamic and weak/strong. The article referred to is quite long and more detail than most people want. I think a section of about one page is long but not too long. These concepts are important to understanding programming languages. Does anyone else have an opinion? Ideogram 08:05, 4 June 2006 (UTC)
I have stripped away a lot of excess detail and tightened up the writing. The result is about half the size. What do you think? Ideogram 05:08, 5 June 2006 (UTC)

I have committed the Elements section to the current article. This completes the majority of the merge. Ideogram 21:46, 4 June 2006 (UTC)

[edit] WikiProject Programming languages

I am trying to revive Wikipedia:WikiProject Programming languages. Ideogram 16:39, 3 June 2006 (UTC)

[edit] PL/I and Algol

Notes on my recent change:

  • Algol was developed in Europe by a consortium of Americans and Europeans. I think PL/I was developed at IBM's lab in Stuttgart Hursley (England), presumably with input from the rest of the company. PL/I may have won for political reasons, but it was not only because Algol was perceived as "European". See, for example, the reasons the MULTICS project chose PL/I.
Agreed, not only -- but a major cause (but only mentioned in a comment, anyway). quota
  • PL/I has not influenced later language design on a scale comparable to Algol. If you do a diff between Algol and PL/I, very little of that diff survives in later languages, whereas a great deal of the Algol core does.
Given that many of the keywords are the same, it's hard to be definite. However, certain key words such as real and begin from Algol have died out almost completely, whereas the PL/I equivalents (float and do) are ubiquitous, and many scripting languages (such as the REXX family) follow PL/I closely. quota
  • PL/I notation is not widely used in pseudocode. Look at the code examples in the PL/I article. This doesn't look much like the pseudocode used in, say, Knuth or Cormen/Leiserson/Rivest/Shamir.
Those are all 'academic' sources (which certainly do tend to follow Algol, due to its use by ACM, etc.). In commercial programming, PL/I-like code and pseudocode are prevalent. quota
  • I don't see any harm in selecting a few languages that were influenced by Algol. I chose Simula, Scheme, Pascal, and Modula because
    1. The influence in these cases is especially obvious; all except Scheme adopt and extend Algol syntax, and all incorporate arbitrarily nested block-scoped procedures.
    2. They were directly influenced, as opposed to indirectly influenced via another language.
    3. These languages have, in turn, been influential in the design of other languages
Not many languages satisfy these three criteria. It can be argued, for example, that Java was influenced by Algol, but Java's direct antecedents were Smalltalk and C++, not Algol. By contrast, the Scheme designers adopted lexical scoping directly from Algol; at its inception, Scheme was essentially Lisp + Algol.
OK. quota

--- k.lee 20:29, 3 June 2006 (UTC)

[edit] APL

There should be some mention of APL under History. I don't know enough to write it. Ideogram 16:15, 4 June 2006 (UTC)

Why APL specifically and not say Snobol or any of the several other fringe languages that have been around for a long time? Derek farn 22:34, 4 June 2006 (UTC)
APL has notably unusual characteristics. It was the first array-oriented language and can be said to have started a paradigm. It was influential on functional programming. It is notoriously dense. It and its descendants are still used today on Wall Street.
I'm not familiar with SNOBOL, it seems to me largely notable for its string-handling.
There is not a clear dividing line, of course; if someone wanted to argue for SNOBOL I would be willing to consider it. But I think APL holds a pretty special place in programming language history. Ideogram 23:33, 4 June 2006 (UTC)
The problem I see is that people are going to start adding in their own favorite influential language. I would not be surprised if this starts to happen with the Fortran, Cobol, Lisp list of 'first' modern languages. Derek farn 23:58, 4 June 2006 (UTC)
I doubt that would happen. And if it does happen, the Wikipedia way is to resolve it with discussion and by consensus. Does anyone else have an opinion on APL? Ideogram 00:11, 5 June 2006 (UTC)
I've used APL (a lot, long ago), SNOBOL (not much), FORTRAN (some), LISP (more), COBOL (with a gun to my head), and C/C++ (untold hours) since early in their inception. I guess I'm the living dinosaur in the crowd. In a historical account of the day, SNOBOL is distinctly less important than APL. SNOBOL has a relationship to Perl about on par with the important, yet once or twice removed influence of Simula on Java. APL, along with LISP, is the partial progenitor of the functional programming idiom. APL provided the first spreadsheet-like interactive console well suited to teletypes with that strange yellow paper, the better implementations were among the first examples of just-in-time compilation, it was a pointer/reference free language that managed the free store interactively. The mathematical primitives were powerful enough that it spawned a dedicated class of vector processing machine (much like Java's JVM). It was one of the first languages to make an interactive time-share service possible. IP Sharpe was well established in the "Grid computing" game back in the late 1970s with APL as the core vehicle. APL proved especially well suited to statistical analysis and gained a strong commercial foothold in the actuarial business. Anyone who gained fluency in APL continued to use it as a RAD tool for algorithm development long after it was widely conceded that APL code was unmaintainable. Imagine trying to operate a timeshare service on COBOL over 300 baud dial-up networking. On glass interfaces, the APL workspace was surprisingly spreadsheet-like. It usually provided a huge back-scroll buffer. You could scroll back to any line, edit the contents of the line, then press enter to reinvoke the command, whose output was then appended to the session log. Problems: use of the overprinting Greek character set was elitist and non-standard, it had the software engineering robustness of writing an orbital mechanics package in Microsoft Excel (I'm sure it could be done, but would you *want* to maintain it afterward?), it had terrible support for heterogenous aggregates (combining strings, booleans, integers into the same data structure), no support for a function call taking more than two arguments, and no structured programming iteration constructs (while, for, if/else). On the contrary, it strongly encouraged the use of its powerful set of mathematical primitives to make iteration and conditional statements unnecessary, or to use recursion to express those ideas wherever possible. In effect, it pushed you in a functional programming direction whether it was immediately convenient or not. In my own opinion the worst defect of all was having no way to create or maintain a library independent from the active workspace. What you would do is maintain a workspace with a set of related library primitives (and funny prefixes on the function names to designate their kinship) and then *import* each library workspace into the application workspace separately, such that the application workspace gained a copy of all the imported code (and any interactive global variables that came with it). No APL I ever worked with allowed to workspaces to be active concurrently. To maintain a library, you had to save your application workspace, load the library, change and debug it, then save it, reopen your application, import a fresh copy of the changed code, and cross your fingers. If internal functions of the library workspace were deleted, you would still have these lingering around in your application workspaces unless you conscientiously rooted them out. As applications scaled, the application workspace became the worst kind of mosh pit one could imagine. This sounds worse than it was in practice. APL was so concise, you were still in RAD mode when the same programming effort in another languages gained the scale of a graduate school dissertation. C++ as a language remains partially crippled by drawing into itself assumptions that prevailed when C itself was first conceived. APL died because it was designed toward using a 110 baud yellow paper teletype as a quick and dirty way to gain *interactive* access to the computational power of a Cray-like supercomputer. As a physicist (most early APL programmers were physicists by training) you could get a *lot* done in that crappy paper console environment. Everything that made APL great in that respect equally made it one of the all-time nightmares in software engineering. The horror you rarely ever had to deal with was sloppiness. Like they say about Haskell now, it wasn't easy to write bad code that worked at all. I learned everything important I now know about software engineering from my days with APL: because it never pretended to address the problem in part measure. When I'm contemplating an algorithm, I use my APL brain; when I'm contemplating any other aspect of program creation, I use *anything* else. The essential feature of the APL experience is that the language was extremely stark: both for what it offered, and what it didn't. By contrast, as much as I can recall about SNOBOL, it the kind of overstuffed PL/1-ish syntax that causes you to drag your old sofa out to the curb in hopes someone is dull enough to think it might be a good idea to drag it off to a new home. I couldn't sit down to SNOBOL now with the overwhelming sense that I was on the production set of "That Sixties Show". The notion of textual representation (strings) as a fundamental data type leads all the way through Perl and SGML to modern XML. In its soul, APL had the tightest kinship to LISP. Everything at the surface was a study in contrasts: homogenous arrays vs heterogenous lists, rigid infix notation with extremely spare use of parentheses vs rigid prefix notional with maximal use of parentheses, streamlined large-scale statistical analysis vs logic-heavy expert systems. An interesting point about LISP is that it guessed wrong about certain major classes of applications. Speech recognition was first tried from the expert system approach and never worked very well; later it was approached from the Markovian perspective (a more APL-friendly computational framework) and it worked fine. LISP is too much in the heavens for its own good. I always found it easy to flip between APL and LISP because they shared the same soul. Except I vastly preferred mentally disentangling the rich and distinctive set of Greek letter to the generic uninformity of the parethetical hinterland. APL was like the Chinese ideographs: once you learn them, ideas jump straight into your mind, completely bypassing one level of intermediate processing. LISP is the modern day Hawaaiin. What does that language have, about ten letters to the alphabet? One thing I would like to point out very strongly about APL, it was the first language that caused you to mentally read f(g(x)) as (fog)(x) on a very deep level. The people who couldn't make that shift just couldn't function in APL at all. You thought of yourself as composing the operators, not cascading data through a succession of function calls. For that reason I say APL was highly influential in the functional programming camp that originated later. For that reason APL forced you to confront certain aspects of your programming talent in a way that FORTRAN or COBOL never could. If you survived the experience, it made you stronger, permanently. Even when APL was already on the out, people approached APL in the same spirit that people now approach Ruby: it could make you think in new ways. An experience that Java never offered. The corporate forces don't necessarily want programmers to think in new ways so languages like Ruby end up with a cultish overtone (through no fault of its own). I haven't had the APL feeling again until C++ introduced (more precisely, reluctantly stumbled into) template metaprogramming. Liberating on certain interesting levels if you survive the experience. Does any of this warrant a comment in the main text? I think a few extremely concise sentences about APL are warranted. Iverson would like that. MaxEnt 22:24, 8 June 2006 (UTC)

[edit] deletion of "Purpose"

I think there needs to be a wider debate on whether this needs to be deleted. Deleting an entire section is a pretty major change. Obviously I thought it was useful since I included it in the merge. Any other opinions on this matter? Ideogram 21:41, 4 June 2006 (UTC)

I think it is a useful section, too. I agree with the person who deleted it that it doesn't cover all programming languages, but the solution isn't to delete the section. The solution would be to improve it. Brief mention of visual languages and logic-based languages might be welcome. (Logic programming actually contradicts some of what the section says—it does fill in the gaps, rather than requiring a step-by-step path.) I think a larger problem is that much of the section didn't discuss their purpose so much as how they work and are used. Those aspects are important, but perhaps could be restructured a bit. In any case, I am in favor of restoring what was deleted—even if it could be improved, removing it seems detrimental to me. – Zawersh 22:02, 4 June 2006 (UTC)
This Purpose subsection was added relatively recently and contains a mismash of different ideas. I'm sure that some of these would be of interest to readers (eg, the practical problems associated with writing programs), while others are simply wrong (eg, the idea that all programs express computation and that all programming languages require an exact specification). Other wording reads like a novel (eg, "In return for this exacting discipline, programming languages reward the user with a unique power:"). Derek farn 22:29, 4 June 2006 (UTC)
I think the definition of computation as "the task of organizing and manipulating information" is sufficiently general to cover all programming languages.
Even high level and logic programming languages require a degree of exactness from human programmers not present in natural language. The statement that computers "have only limited ability to 'understand' human language" is exactly right in my opinion. There is the paragraph at the end which mentions that languages have developed to "let programmers express ideas that are more removed" from the hardware.
As for wording, that can be easily corrected without deleting the whole section. Ideogram 22:42, 4 June 2006 (UTC)

As for a "narrow view", the vast majority of programming languages are procedural. An encyclopedic overview of the subject can be forgiven for concentrating on this paradigm. And even functional languages can't infer everything from a "what" description, they need some details about an algorithm to proceed. Ideogram 21:50, 4 June 2006 (UTC)

This claim is a bit fuzzy. FP folks contrast FP with "procedural", which leaves a "vast majority" on the other side (except for "delarative" and "logic" programming, which are sort of in neither place). OOP folks, however, often contrast OOP with procedural programming. Obviously, for FP folks, OOP is a type of procedural, but OOP folks tend not to characterize it that way. OOP programming is certainly widespread enough not to leave a "vast majority" outside of it. LotLE×talk 01:10, 5 June 2006 (UTC)

[edit] Should be restored

Copy of whole text: /Purpose

I've been asked to take a look at this dispute. At first brush, it seems to me that the "Purpose" section contains several relevant concepts that are not elsewhere addressed in the article. There is a bit too much of a advocacy tone in the section, I think, but the general idea of pointing to the requirement for formalism and contrasts with natural and other artificial languages/codes seems quite relevant. I think maybe it could use a little bit of tweaking, but in general the section should be restored. LotLE×talk 01:04, 5 June 2006 (UTC)

[edit] Purpose

The title Purpose does not describe the contents below. Derek farn 22:51, 4 June 2006 (UTC)
Can you suggest a better title? Ideogram 23:26, 4 June 2006 (UTC)
This is really a mishmash of material that should be scattered over various subsections or not included. Derek farn 01:13, 5 June 2006 (UTC)
This is an important question, though the current answer is not extremely well organized. But having made the point about Turing completeness above, the obvious question for the reader is, why are there so many of these things if they're really 'all the same'? kraemer 03:20, 14 June 2006 (UTC)

Like other specialized languages, such as musical notation and mathematical formulae, programming languages facilitate the communication of a specific kind of knowledge, namely, computation, or the task of organizing and manipulating information. For example, a programming language might enable its user to express the following:

Um, yes. It would probably need to be specific. kraemer 03:20, 14 June 2006 (UTC)

Programming languages differ from most other forms of human expression in

Should say "Some programming languages ..." Derek farn 22:51, 4 June 2006 (UTC)
Exception? kraemer 03:20, 14 June 2006 (UTC)

that they force the author to write instructions with exceeding precision and completeness. In a natural language, or even mathematical notation, authors can be ambiguous and make errors. For example, consider natural

Mathematical notation can contain errors? So can programs, but they are not intended. Derek farn 22:51, 4 June 2006 (UTC)
Mathematical notation written on a chalkboard in a lecture often contains errors that may or may not confuse students. Ideogram 22:56, 4 June 2006 (UTC)
More to the point, a certain amount of syntax abuse isn't only acceptable when expressing a mathematical idea, it can often be helpful, at least to people who are trying to get a first-pass intuition for something. 03:20, 14 June 2006 (UTC)

language:

  • Speakers can leave things out, because humans excel at "filling in the gaps" of a partial statement. If someone says: "Going to the store," the listener might use the context to fill in the missing words: "I am going to the store on the corner."
A number of languages allow programmers to leave things out and the compiler figures out what was intended. Derek farn
This could be reworded, but the point is that humans "fill in the gaps" much better than any compiler ever did. Ideogram 22:57, 4 June 2006 (UTC)
Depends on the requirements of the language. Cobol has all sorts of implicit behavior (one of the design aims was to make it English language 'like'. PL/1 requires support for all sorts of implicit conversions and figuring out what behavior actually occurs can be a major undertaking. I'm sure an article discussing the trade-off between expressive power, ambiguity, programmer convenience, and likelihood of a mistake being made would be of interest to many people. Derek farn 01:13, 5 June 2006 (UTC)
You can't possibly argue that COBOL or PL/1 approach the ambiguity and error-correcting features of natural language. Ideogram 01:20, 5 June 2006 (UTC)
Natural languages do not have error correcting features. Most human communication contains a great deal of redundancy, while programming languages have much less redundancy. Derek farn 10:44, 5 June 2006 (UTC)
Natural languages are spoken by humans who use the redundancy in them to correct errors. This is purely a semantic argument and is not productive. Ideogram 15:07, 5 June 2006 (UTC)
Agreed. kraemer 03:20, 14 June 2006 (UTC)
  • Speakers can make grammatical errors, because humans excel at compensating for minor errors in language. If someone says, "I am going to the store am the corner," the listener can usually tell that "am" is meant to be "on".

But because computers are not yet able to "fill in the gaps", and have only limited ability to "understand" human language, every part of every computation must be expressed explicitly and exactly in a programming language.

Not true. To start with logic languages require users to specify the what, not the how. Some languages (eg, SQL) do not provide no means of specifying any computation. Derek farn 22:51, 4 June 2006 (UTC)
Please note the definition of computation used at the top of the article: "the task of organizing and manipulating information". This is not equivalent to specifying an algorithm in a procedural manner. Ideogram 23:00, 4 June 2006 (UTC)
My point was that programs is some languages do not express computations. Derek farn 01:13, 5 June 2006 (UTC)
In what sense do logic languages and SQL not perform "the task of organizing and manipulating information"? Ideogram 01:21, 5 June 2006 (UTC)
But that's exactly the point. Logical languages specify the result of a computation, and it's up to the compiler to figure out how to make it happen. It's extremely misleading to say that "every part of every computation" is expressed "explicitly" -- the entire point of a computer language is to make the predictable and boring bits implicit, while communicating to the reader the parts that really matter. kraemer 03:20, 14 June 2006 (UTC)

Each phrase in a program corresponds unambiguously to its literal meaning, and no more.

"... its literal meaning..." What about phrases that have unspecified, undefined, or implementation defines behaviors? Derek farn 01:13, 5 June 2006 (UTC)
Conditional agreement -- this is true with respect to implementations, but not to specs. kraemer 03:20, 14 June 2006 (UTC)

If the author of a program states that the program should perform an incorrect step, the program's meaning will include that incorrect step. If the author omits a necessary step, the program's meaning will not include that step. Therefore, in order to write a "correct" program, the author must be correct in every detail.

This belongs in an article on writing programs, not on programming languages. Derek farn 22:51, 4 June 2006 (UTC)
I agree this can be deleted. Ideogram 23:01, 4 June 2006 (UTC)

In return for this exacting discipline, programming languages reward the user with a unique power: Many programming languages are executable by an electronic computer.

This belows in a pulp novel, or if it must be included then in an article on writing programs. Derek farn 22:51, 4 June 2006 (UTC)
The wording could be improved, but the point that programming languages are executable languages is pretty critical. Ideogram 23:02, 4 June 2006 (UTC)
It's silly, but true. It should clearly be rephrased, but if you can manage to clearly describe your problem in a compilable language, you're not gonna have to bust out the slide rule. kraemer 03:20, 14 June 2006 (UTC)

In other words, tasks expressed in most programming languages can be performed autonomously by a computer, without human intervention. Therefore, programming languages have enormous practical utility; they enable the construction of programs that automatically perform tasks. The entire information technology industry is built around the construction and use of programs. A programming language implementation is a system that enables a computer to execute a program written in a programming language. Programming languages can be implemented by an interpreter, a compiler, or some combination of both.

This belongs in an introductory text on computers. Derek farn 22:51, 4 June 2006 (UTC)
This could be deleted; the point about interpreters and compilers is useful but duplicated elsewhere. Ideogram 23:04, 4 June 2006 (UTC)
Agreed kraemer 03:20, 14 June 2006 (UTC)

Many languages have been designed from scratch, altered to meet new needs, combined with other languages, and fallen into disuse. Although there have been attempts to make one "universal" computer language that serves all purposes, all of them have failed. The need for diverse computer languages arises from the diversity of contexts in which languages are used:

Good points. This needs to be said somewhere. Derek farn 22:51, 4 June 2006 (UTC)
  • Programs range from tiny scripts written by individual hobbyists to huge systems written by hundreds of programmers.
  • Programmers range in expertise from novices, who need simplicity above all else, to experts, who may be comfortable with considerable complexity.
  • Programs may need to extract the right amount of performance on platforms ranging from tiny microcontrollers to supercomputers.
These are actually rather similar -- in both of these contexts we're normally trying to squeeze maximum performance out of limited resources. The true contrast is actually with home computers, which usually have lots of spare cycles to spend on chrome. kraemer 03:20, 14 June 2006 (UTC)
  • Programs may be written at one time, to reflect some exacting constraints, and then not changed for generations, until these constraints change, or they may undergo nearly constant modification.
This is really important, but not really about programming languages -- it's more about technique. 03:20, 14 June 2006 (UTC)
  • Finally, programmers may simply differ in their tastes or habits: they may be accustomed to discussing problems and expressing them in a particular language. Languages like COBOL and 'C' proved surprisingly persistent despite some deficiencies often observed. Some credit William H. Gates III's devotion to BASIC for keeping that language alive to this day.

One common trend in the development of programming languages has been to add more ability to solve problems on a higher level.

Another trendy has been towards simpler languages that do everything through librray calls. Derek farn 22:51, 4 June 2006 (UTC)
I don't know if you can call this a "trend"; C certainly was a simple language that did everything through library calls. Ideogram 23:06, 4 June 2006 (UTC)
This definitely isn't a "trend" -- some especially good languages for high-level expression of various types of abstract computation include LISP, APL, and haskell -- I challenge anyone to fit a meaningful temporal model. kraemer 03:20, 14 June 2006 (UTC)

The earliest programming languages were tied very closely to the underlying hardware of the computer. As new programming languages have developed, features have been added that let programmers express ideas that are more removed from simple translation into underlying hardware instructions.

Good points, needs some rewording. Derek farn 22:51, 4 June 2006 (UTC)
Agreed. The ideas aren't more removed; their expression is. kraemer 03:20, 14 June 2006 (UTC)

Because programmers are less tied to the needs of the computer, their programs can do more computing with less effort from the programmer. This lets them write programs in ways that are closer to the way they think about the problems they are solving. It also lets them write more programs in the same amount of time. And because the programs are written more like how they think about the problems, it is easier for a new programmer to understand a program that was written by somebody else.

A very bold claim. Where is the evidence? Derek farn 22:51, 4 June 2006 (UTC)
It has long been known that higher-level languages are more productive than lower-level languages. From "The Mythical Man-Month", pages 93-94:
"Corbató ... reports ... a mean productivity of 1200 lines of debugged PL/I statements per man-year ...
" ... Corbató's number is lines per man-year, not words! ...
"* Productivity seems constant in terms of elementary statements, a conclusion that is reasonable in terms of the thought a statement requires and the errors it may include.
"* Programming productivity may be increased as much as five times when a suitable high-level language is used."
Ideogram 23:27, 4 June 2006 (UTC)
Interesting quotes, do you have a reference? See: Lutz Prechelt. "The 28:1 Grant/Sackman legend is misleading, or: How large is interpersonal variation really?" Technical Report iratr-1999-18, Universität Karlsruhe, 1999. for an example of how results in 'old' papers get misunderstood and an urban legend is born. Derek farn 01:13, 5 June 2006 (UTC)
I included the reference above, "The Mythical Man-Month". Even if you think it's an urban legend the fact that it's verifiable makes it fair game for inclusion in an encyclopedia. Ideogram 01:17, 5 June 2006 (UTC)
There are a few claims there. Which are you calling into question? Just the last bit, "it is easier for a new programmer to understand a program that was written by somebody else", or other parts as well? – Zawersh 01:46, 5 June 2006 (UTC)
I am calling all of them into question. If you read old papers you will find that many of them are based on very small sample sizes and the results are open to several interpretations. Go read about the Grant/Sackman urban legend, this has been repeated in umpteen books and is incorrect. Derek farn 10:44, 5 June 2006 (UTC)
I looked up Grant/Sackman and skimmed over it. What I read indicated that it deals with variance in productivity due to differences in individual programmers. It didn't seem to address high-level versus low-level languages. I'm not sure if you're citing it only as an example that old papers can lead to "urban legends" or if you're citing it as evidence against this passage, but it only seems to work for the former. (Unless I'm missing something?) I'm not a huge fan of the passage above, but it does express one idea that seems fairly obvious to me: as a generalization, high-level language allows for more productivity than lower-level language. For example, if someone is working in the medical imaging field, they'll be able to develop software solutions for many problems much faster and probably more accurately with IDL than with an assembly language. I did a quick bit of searching last night and wasn't able to find any papers that directly support this (nor did I find any that contradict it), but it seems pretty self-evident to me. It does of course have exceptions: low-level device drivers and operating systems would be hard to write in high-level languages. It also has caveats: a language that doesn't target one's problem domain may not be as successfully used as another language that does. But the fundamental concept seems sound. Having written all this, however, I'm realizing that perhaps this is something that should go into a different section. A major aspect of using programming languages is selecting the right one for a given task. Would a short section on that topic, covering the few points I just mentioned, be appropriate for this article? – Zawersh 13:09, 5 June 2006 (UTC)
Let's see a more relevant reference. That's the way we do things here, if you argue for something, you have to verify it. Saying it's an old paper doesn't cut it. Ideogram 15:12, 5 June 2006 (UTC)
Zawersh you are right to say that my point was to illustrate how urban legends grow up around rarely read papers. For as long as I can remember it has been popular to cite "The Mythical Man-Month" as the reference for some software engineering theory. Brooks cites the Sackman/Grant paper (Chapter 3 note 1) for his source of a 25-1 productivity difference and I suspect that many of his other references are themselves of poor statistical quality or are misquoted. Brooks is a great read and people are still making the mistakes he experienced, but he is not the font of software engineering knowledge. Derek farn 18:44, 5 June 2006 (UTC)
You aren't going to make much headway by arguing against the reliability of widely respected sources. This is about verifiability, not your opinion that he is "not the font of software engineering knowledge." Ideogram 19:03, 5 June 2006 (UTC)
I'm sorry, but does anyone actually think that this isn't true, at least in the limiting case? Seriously, who writes all of their code in assembly? Even if you think that things have been going downhill since FORTRAN 2, you don't have to be Paul Graham to believe that it's easier to understand code that's written in a higher level language. kraemer 03:20, 14 June 2006 (UTC)

[edit] thank you all participants

I would like to thank all of you participating in editing and discussing this document, even the ones I disagree with. It is exhilarating to work with equally talented peers on a subject of shared interest. Ideogram 04:12, 5 June 2006 (UTC)

[edit] History merge

I propose that the content from the History section be merged into History of programming languages. Right now, that article is a skeleton without much content. It has the potential for being a rich article, and it would allow for greater detail to be included than would be appropriate for this article. The history section in this article could then be either condensed or left as is, but with a link to History of programming languages as the main article for the section. Any thoughts? – Zawersh 13:20, 5 June 2006 (UTC)

Sounds like a good idea. Ideogram 15:09, 5 June 2006 (UTC)

You can go ahead and copy content to History of programming languages and discuss how to edit this article as a separate step. Ideogram 15:24, 5 June 2006 (UTC)

I've copied the history section to the history article, weaving in the bits of possibly useful content that were already there. If anyone objects, feel free to revert and provide feedback either here or in the history article's talk page. I'm not too knowledgeable on the history myself, so I won't be able to expand it much myself, but hopefully it will encourage additional contributions. Given that there's so much conflict at the moment, I'm going to hold on off doing anything in this article until things have calmed down some lest I introduce another point of contention. – Zawersh 03:56, 6 June 2006 (UTC)
Thank you. Ideogram 03:57, 6 June 2006 (UTC)

[edit] syntax edits

I feel User:Derek farn's edits here add words without adding content. Please discuss. Ideogram 19:47, 5 June 2006 (UTC)

  • "purely" doesn't really add content here.
  • Derek farn seems to have something against semicolons. I feel they are a valid punctuation mark that reduces wordiness.
  • The clarification that symbols can be words and punctuation marks is unnecessary. We already mention graphical programming langauges are "more" graphical, and "symbols" is usually understood to include letters and punctuation marks.
  • "the following examples" there is only one example, and some discussion of lexical structure and BNF precedes it.
  • "The following example" is wordy.
  • Language specification is a difficult subject and rather than try to explain it I prefer to delete the undefined term.
  • There is a parallel sentence structure here that makes the analogy between having bugs and having a false sentence. We need to explain that a syntactically correct program may not have the effects the programmer intended.
  • The final statement is true of all natural languages, not just English. And we don't have to mention we are using English as an example, that is self-evident.

Ideogram 20:24, 5 June 2006 (UTC)

"Meaning can only be defined by a language specification." Most language specifications (ANSI standards for instance) focus on syntax. Fully specifying a language semantics implies a formal language, which does not correspond to any widely used language. Furthermore even a formal language must leave out details of the programmers intent which I submit is a large part of programming semantics. Ideogram 20:30, 5 June 2006 (UTC)

It sounds like you have never read any non-toy language specfications. Unfortunately the ANSI ones cost money (although only $19 each for C and C++). The Java language spec can be downloaded free from Sun's web site. Your local univrsity library may hold copies of ANSI Standards. Anyway, go and read some and see how littl eof the material is syntax related. Derek farn 20:50, 5 June 2006 (UTC)
Ultimately it comes down to verification. If you can verify this statement, I will accept it. Ideogram 20:52, 5 June 2006 (UTC)
Most language specifications define semantics. See, e.g.:
Hopefully that's a broad enough sampling. k.lee 21:43, 5 June 2006 (UTC)
The emphasis on semantics is beyond dispute. APL and LISP can define their syntax almost on a single beer napkin. Neither of those languages have keywords such as "const", "volatile", "template" or "using" to muddy the waters. APL has no syntax to declare or describe types at all. It defines a few type literals (character strings, integers, floats) otherwise type is always inferred. Almost the whole of the language was the elegance of the extended mathematical operator set. Here's a data point from the C language:
 
  char* p = malloc (0);
  char* q = malloc (0); 
  assert (p != q);  
  if (p) free (p); // error to free p otherwise 
  if (q) free (q);
First, there was a tempest about whether the language is required to accept malloc (0) as a valid operation; I think it ended up being implementation defined because some "protect the user" implementations refused to remove their lint detector concerning this construct. Another camp (of which I'm a long standing member) was horrified to see zero treated as a special case value.
The language defines that no two concurrently valid memory blocks returned from malloc() have the same address, so you can compare p with q to determine if they came from the same (successful) malloc. Since NULL is used to represent an invalid allocation, the language defines it as an error to attempt to free it again. These are the super nitpicky details that every language standard is made from.
Another infamous semantic dispute is the definition of the modulus operator for negative integers. I tend to put my weight behind establishing the simplest and strongest invariant.
  unsigned int mod (int x, unsigned int m) { 
    unsigned int r = x % m; 
    assert (0 <= r && r < m); // elegant semi-open invariant 
    return r; 
  }
You can argue for an elegant reflection symmetry to handle integer m capable of taking on negative values. Worthless in the C langauge because the pointer dereference operator is not available in a reflected complement (if you think of a pointer as being like a stick cursor in a text document there the "next" character is different depending on which direction you are interating). Which means that negative modulands have effectively no practical application because the language doesn't inately support reflection transformations. Given that realization, what do you impose on the language standard? Bear in mind that code to conform to a strict definition can sap your performance in the common case that occurs 99.999% of the time. The invariant above would require that the modulus operator return zero always when m <= 0. Not much of an imposition on the implementation, but you have to be wary about the type returned:
 template <typename T> T (int x, T m) {
   unsigned int r = 0; 
   if (m > 1) r = x % m; 
   assert (0 <= r && r < m); // elegant semi-open invariant 
   return r; 
 }
And no, I'm almost 100% sure than neither C/C++ nor any other language I've used defines modulus this way. It wasn't until Eiffel came along and fully internalized some of what Dijkstra had to say that the simplicity and strength of invariant return became the conscious centerpiece of the analysis. If the invariant requires a non-negative return value, maybe the return type should be an unsigned quantity? That interacts with the C type system further downstream in the same expression, in perhaps surprising ways. In the C language, where subscripting an array with an negative index is easy to do, and not so often what you intended, do you really want to encourage arithmetic primitives to return negative values more than practical considerations would dictate? In a language that promises to catch every such mistake (at compile time when possible, or at run time) you might have different sensibilities on this matter.
Languages standards are etched in green cheese. There are no turtles. It's green cheese, all the way down. The moldy rind (syntax) is the least of your concerns. The C++ standard devotes about a 100 pages to template argument function overload resolution, and hardly any of that concerns the syntax of template function declarations or function invocations. MaxEnt 01:16, 9 June 2006 (UTC)

[edit] programming language implementation

This is currently a broken link. Does anyone intend to write this article? If not, I prefer not to include it. Ideogram 20:50, 5 June 2006 (UTC)

Added a stub. Not entirely satisfying, but IMO this is important to have an article that unifies the common material in compiler, interpreter, virtual machine, etc., and adds some discussion of the principles of runtime systems and other pragmatics. See the category for a subset of the stuff that should be discussed in programming language implementation eventually. k.lee 21:35, 5 June 2006 (UTC)

[edit] purpose rewrite

I have edited the purpose section in my copy at Talk:programming language/merge to condense it and try to address some of the objections. Please feel free to edit and comment. Ideogram 21:03, 5 June 2006 (UTC)

Why do you persist in trying to add this mish-mash of disjoint ideas and poor rewrites of existing material? Derek farn 21:31, 5 June 2006 (UTC)
I think you need to concede that consensus is that this is a useful section. You make good points and we value your participation in making it better but it looks like deleting it entirely is off the table. Ideogram 21:36, 5 June 2006 (UTC)
You can of course write your own version from scratch that addresses the same goals and we can discuss it, but deleting the section entirely is not the way to achieve that. Ideogram 22:02, 5 June 2006 (UTC)
Anybody here know how to put a section up for a vote? Derek farn 21:48, 5 June 2006 (UTC)
Fine, let's have a vote.
I seem to recall there is a procedure to follow. POinters anybody? Derek farn 21:56, 5 June 2006 (UTC)
See Wikipedia:Straw polls. However, note that Wikipedia is not a democracy. --Allan McInnes (talk) 23:27, 5 June 2006 (UTC)
Well apparently a vote is not binding anyway. How do you propose to resolve this? I suggest you write your own version from scratch. If you can't or won't do that, we are left with this, which is better than nothing. Ideogram 23:44, 5 June 2006 (UTC)
My problem with this material, as a subsection, is that it tries to cover too broad a range of subjects. There are a number of points it discusses that belong in an article on programming languages. Let's put each point in the subsection in which it belongs (open to suggestions on this point). This is not a standalone article. Let's cut out the 'good' parts and merge them into the existing material. Derek farn 00:43, 6 June 2006 (UTC)
Please see User talk:Allan McInnes#voting procedure for an outline of how to approach this debate. Ideogram 00:02, 6 June 2006 (UTC)
Do you agree we need a subsection describing why programming languages exist, and what need they fill? Ideogram 01:57, 6 June 2006 (UTC)
Why they exist? You mean the economic considerations that favor them over writing in hex or assembler? Sounds useful. Derek farn 02:02, 6 June 2006 (UTC)
The average layperson doesn't have a clue what hex or assembler is. The average person does have a clue what natural languages are, and may wonder about the relationship between programming languages and natural languages. In fact, when I explain what I do for a living to laypeople, this is one of the most frequent questions. I have never in my life been asked by a layperson why people program in high-level languages rather than hex or assembler, because programmers are the only people who even know about those things, and they already know the answer. The motivation for high-level languages should also be in the article (and, indeed, it is already mentioned under the history section), but first the article needs to explain why programming languages need to exist at all. k.lee 02:25, 6 June 2006 (UTC)
The current "purpose" section covers these points:
          • Programming languages facilitate communication
          • Programming languages are different from natural languages
          • Programming languages are executable
          • Many languages are needed for different contexts
          • Programming languages have become higher level
Which subtopics do not belong here? Ideogram 02:29, 6 June 2006 (UTC)
  • Approve. Ideogram 21:52, 5 June 2006 (UTC)
  • Approve. k.lee 21:58, 5 June 2006 (UTC) (Considerable rewrite may be needed, but I think we obviously need a section that explains why programming languages exist.)

[edit] Quick poll on "purpose" section

I see some "votes" above, but it's not clear exactly what they are "approving" of. I believe a clarification would allow the votes to be more meaningful. How about:

Should a section entitled "purpose" be included in this article? If included, such a section would attempt to highlight differences between a programming language as formalized artificial language and a natural language. In particular, such a section would emphasize the relative error intolerance of programming languages and their ability to instruct a computer to carry out computations.

[edit] Support inclusion

  1. LotLE×talk 02:12, 6 June 2006 (UTC)
  2. Allan McInnes (talk) 02:34, 6 June 2006 (UTC)
  3. Ideogram 02:37, 6 June 2006 (UTC)
  4. Zawersh 03:35, 6 June 2006 (UTC)

[edit] Oppose inclusion

[edit] library section

I'm not sure we need a library section. Although the line is fuzzy, and many languages come to be intimately tied to their standard libraries (C comes to mind) strictly speaking libraries are not part of programming languages. Harbison and Steele discuss the C library in what amounts to an appendix, and say "Many facilities that are used in C programs are not part of the C language as such but are part of 'standard libraries' ...". Ideogram 23:02, 5 June 2006 (UTC)

The line does become fuzzy as you cast your net wider, but i think most non-trivial programming languages have a definite standard library "core" which, in practice, is at least as important and fundamental to the language as its syntax and semantics. Some examples:
  • Haskell's Prelude
  • Java's java.lang namespace (which is required by (among other things) syntactical constructs like the enhanced for loop)
  • Python's "builtin" namespace (which Python's name resolution rules treat specially, besides the "local" and "global" namespaces)
  • Scheme's standard procedures, and Smalltalk's base library (which are responsible for implementing the majority of the control and organizational constructs that other languages consider "syntax", despite the fact that they hold no special syntactic status within their language definitions)
(I think C is actually an exception, by the way, in that the language isn't particularly tied to its standard library: a lot of C's success in domains like embedded system programming is probably due to the fact that the standard library can be treated as an "optional extra", without impacting the language much. Equally, at the other extreme, it's not uncommon for big applications to use runtime libraries like GLib, APR, and NSPR as more capable "libc replacements".)
--Piet Delport 01:53, 6 June 2006 (UTC)
Most language reference manuals describe a standard library. k.lee 02:27, 6 June 2006 (UTC)
It was an explicit design goal of the C language to not tie itself strongly to its standard library, and that perspective was strongly adopted by Stroustroup in his design of C++. Before C, most langauges defined the IO facility as part of the core language. Linux kernel hackers have a different view of their standard libary than application programmers. Note that the C/C++ standards make heavy use of "as if" terminology. In practice, aggressive compilers are free to do a lot at compile time to cheat in the separation of church from state, as long as they do it "as if" the separation were still in force. Both C++ (in the template-metaprogramming idiom) and Perl grant incredible powers to the writers of libraries to reshape the language almost beyond recognition. Template-metaprogramming libraries are compile-time artifacts. Because the C language standard library always made liberal use of #define macros to speed execution, it also had/has strong elements of compile-time binding. Coplien in his book (early C++ years) explains that a big part of what motivated AT&T to pursue software technologies such as C/C++ was the problem of upgrading a complex switch on the fly without ceasing continuous operation. In that context, it's of the utmost concern what portions of your standard library are leaching into your compiled code base. It's possible with C++ (but not much fun, I wouldn't think) to architect a system where you can incrementally relink new code on the fly. Java has much of the same conceptual footing in that area, but I don't know whether anyone has pursued it's use that way in real life; probably Jini has that aspiration somewhere in its genes. Likewise, the notion of the system "library" in a real-time OS such as QNX has a very different flavour to it; often the OS has far more invested in the library than the programming language itself. MaxEnt 00:09, 9 June 2006 (UTC)

[edit] Definitions

I think we need to make clear that this section is intended to discuss ways of defining what a programming language is, rather than ways to classify them. Ideogram 23:38, 5 June 2006 (UTC)

As one of the several authors of the current wording I'm not sure I follow the is/classify distinction. Ideogram please go and read up on a few language definitions before jumping in here. Also please go over the rather protracted discussions and edits that led to the current wording. Derek farn 00:30, 6 June 2006 (UTC)
Since the person responsible for the edits understood what I was talking about, I don't see the need to read up on anything for you. Ideogram 01:54, 6 June 2006 (UTC)
Good catch. Feel free to move my contribution--indeed the whole section, to taxonomy. OTOH, I'm a bit uncomfortable with the weaselish definitions of programming languages we have. "A stylized communication technique"? A bit too imprecise; sounds like someone was trying to avoid offending somebody. No "universally agreed definition"? Perhaps not, but there are several authoritative definitions given by guys like John Reynolds, Michael Scott, and numerous other researchers in the subject who know what they are talking about; FTMP these definitions intersect. I'd crack open a few books (I'm don't have any handy at the present time) and lift a definition from one (or several) of these individuals. Where they disagree, we can acknowledge competing viewpoints; but saying "nobody agrees" is a cop-out. --EngineerScotty 23:48, 5 June 2006 (UTC)
There was no attempt to avoid offending anybody. There is no universally agreed definition and there are plenty of authoritative definitions, most of which are reflected in the current wording. Yes, we could pick the definition given by one individual (I happen to prefer the Turing machine one), but that does not reflect reality. Derek farn 00:30, 6 June 2006 (UTC)
I agree but it's a big can of worms. If you are willing, I encourage you to lead the discussion (enough arrows in my back already :-). Ideogram 23:52, 5 June 2006 (UTC)
It appears that quite a few researches in the subject agree with you. I consulted numerous programming language texts; none of which bothers to define "programming language". They all seem to take the Justice Potter approach--"I know what it is when I see it". :) One definition (not very authorative) that I did locate online, and wasn't obviously wrong, was on die.net:
A formal language in which computer programs are written <http://dict.die.net/programming%20language/>

Wiktionary:

code of reserved words and symbols used in computer programs, which give instructions to the computer on how to accomplish certain computing tasks

Encarta:

special vocabulary for instructing computer: a unique vocabulary and set of rules for writing computer programs

Thoughts? --EngineerScotty 16:49, 9 June 2006 (UTC)

Being that this is Wikipedia, the one from Wiktionary (a sister porject) would probably be best. The page even links to this one on Wikipedia. The page is here: [[1]]. Jaxad0127 16:55, 9 June 2006 (UTC)
FOLDOC is usually a pretty reliable (and has been the starting point for several articles here on WP). Their definition is here. It begins:
A formal language in which computer programs are written. The definition of a particular language consists of both syntax (how the various symbols of the language may be combined) and semantics (the meaning of the language constructs).
--Allan McInnes (talk) 19:12, 9 June 2006 (UTC)

More quotes:

A programming language is a language intended for the description of programs. Often a program is expressed in a programming language so that it can be executed on a computer. This is not the only use of programming languages, however. They may also be used by people to describe programs to other people. Indeed, since much of a programmer's time is spent reading programs, the understandability of a programming language to people is often more important than its understandability to computers.
There are many languages that people use to control and interact with computers. These can all be referred to as computer languages. Many of these languages are used for special purposes, for example, for reserving seats on airplanes, conducting transactions with a bank, or generating reports. These special-purpose languages are not programming languages because they cannot be used for general programming. We reserve the term programming language for a computer language that can be used, at least in principle, to express any computer program. Thus, our final definition is:
A programming language is a language that is intended for the expression of computer programs and that is capable of expressing any computer program.
--Principles of Programming Languages, 2nd ed.
What is a program? At first glance, programs have two different sorts of manifestations. On the one hand, they are documents of some kind that give a series of instructions to be executed by a computer. But these passive documents can be turned into active physical processes: when a program is executed, the instructions in the document are carried out. The program text is passive, but the executing program is an event in real time. Does "program" refer to the passive text, or the active event? The answer is both, because from our point of view in this book, a program is a machine. The program text represents the machine before it has been turned on. The executing program represents the powered-up machine in active operation. There is no fundamental distinction between the passive program text and the active executing program, just as there is none between a machine before and after it is turned on.
So a program is a kind of machine, in particular a "software" machine. There is nothing a program can do that a mechanical machine built out of gears and sprockets can't, but the software version can be built using a programming language on a computer terminal.
What is a programming language? It follows that a programming language is a construction kit for software machinery. The machines we build depend on the interplay betwen tools, materials and imagination. Where software machinery is concernd, programming languages define the tools and materials. Theoreticians note that all general-purpose programming languages are "Turing-equivalent." Ultimately they can all compute the same set of functions, so none is more powerful in a mathematical sense than any other. The analogous observation is that all hardware machines must obey the same physical laws. No software machine can solve the halting problem (can compute a mathematically uncomputable function), and no hardware machine can violate the laws of thermodynamics.
--Programming Linguistics

google define:programming language

[edit] Looking for a home

Not sure where to put this (useful) text I removed; when I replaced the section on "specification" (which includes both syntax and semantics, as well as lots of other stuff) with "semantics":

  • a description of the language's syntax and semantics (e.g., C language). The latter usually lists the results of performing an operation and restrictions on the kinds of operations that can be performed.
  • a description of the behavior of a translator (e.g., C++). The syntax and semantics of the language have to be inferred from this description.
  • a definition in terms of an executable specification (e.g., Prolog), often written in that language.

Perhaps "implementation" should be broken out as a separate section; as it's frequently useful to view programming languages as abstract machines apart from their actual realizations; formal specifications of programming language implementations probably goes there. Plus, use of reference implementations as a means of specification has been ommitted. --EngineerScotty 00:03, 6 June 2006 (UTC)

[edit] semantics

I feel these entries might be too detailed and theoretical for the article. In the textbook references I listed formal methods of specifying semantics are barely mentioned. How often are they really used in industry? I suppose I should read the specifications listed by k.lee above. Ideogram 00:08, 6 June 2006 (UTC)

All right, I'll be honest, I don't understand formal semantics. I've never had to learn them and I don't know how useful they are. I'll leave arguing about this to others.

I think it's important to distinguish between the general definition of semantics and the computer science definition. In a general sense, there are aspects of program semantics that are only understood by the programmer. The computer science definition seems to be closer to "what can be captured in a formal description". I think this difference accounts for my attempt to say that a formal semantics doesn't prevent bugs. Ideogram 00:18, 6 June 2006 (UTC)

Semantic bugs are almost an edge case in actual programs. The easiest way that I can come up with to describe them is bugs that no reasonable compiler/interpreter would reject, but which aren't really bugs in the logic of the program. These are usually defined with respect to a specification. A really simple example comes from scheme. The scheme function EQ? determines whether two objects are the same at the level of addressing. If FOO and BAR are both defined to be the same complicated thing, (say, the string "mumble"), but they neither one was defined in terms of the other, they are EQUAL? but not EQ?. Because it's more expensive to store an address to a cell storing a small integer than it is to just hang onto the integer, most scheme implementations just store the integer itself, so if you use EQ? to test equality, you'll get what you want. Nonetheless, in the official scheme specification, the result is indeterminate, so it's a semantic bug. I hear there's something similar in C such that void main(void) is really allowed to do pretty much anything. A more useful example: imagine that you calculate some value n as a function of the inputs, and then run a loop as k goes from 0 to n. If k is a small integer in a strongly-typed low-level language, and n is bigger than the maximum size for a small integer then you're going to run into problems. This isn't something any compiler could signal an error on (not a syntactic error), but it's not really a sign that your algorithm is fundamentally messed up either (not a computational error). It's a semantic bug. kraemer 03:44, 14 June 2006 (UTC)

[edit] Move taxonomies

We should probably move the taxonomies section to a main article Programming language taxonomy or something. k.lee 01:19, 6 June 2006 (UTC)

Is there any reason to create a new article Programming language taxonomy when Categorical list of programming languages already exists? --Allan McInnes (talk) 01:47, 6 June 2006 (UTC)
Allan McInnes I think this article is current under siege by a few people with a small amount of knowledge and an unwillingness to spend time reading up on this subject. Derek farn 02:05, 6 June 2006 (UTC)
Great, go start your own wiki. Ideogram 02:11, 6 June 2006 (UTC)
How about we all try to keep things civil, and avoid personal attacks? --Allan McInnes (talk) 02:25, 6 June 2006 (UTC)
I would like to request that User: Derek farn try to avoid sarcasm in his edit summaries. Ideogram 02:31, 6 June 2006 (UTC)
The categorical list of programming languages is an alphabetized laundry list. I was hoping that it would be possible to produce an article on programming language taxonomy that a human being could conceivably read. It is clear that the categorical list will never become such an article. k.lee 02:39, 6 June 2006 (UTC)
There are at least two people working on that right now. I think they would welcome your help. Ideogram 02:46, 6 June 2006 (UTC)
I fully support the idea of making Programming language taxonomy its own article. I don't think Categorical list of programming languages is well suited to becoming an actual article, and its title isn't all that appropriate for such an article either. I've been working at transitioning the content in the categorical list into the category system (as well as cleaning up the list). Perhaps if we had a good taxonomy article and the list was redundant through the categories, we might be able to drop the categorical list eventually. – Zawersh 03:25, 6 June 2006 (UTC)

[edit] Mediation Cabal Request

I have submitted this dispute to medcabal. I suggest we all leave these pages alone until they get to us. Ideogram 02:51, 6 June 2006 (UTC)

Mediation Cabal request is here, for anyone interested. --Allan McInnes (talk) 02:56, 6 June 2006 (UTC)
I think Derek Farn has indeed gone a bit overboard with reverts and snide edit comments... but I also know Ideogram is pretty new around here. Cooling down and chilling out is always a good idea, but this disagreement is hardly a ripple in the general sea of disputation among WP editing. LotLE×talk 03:01, 6 June 2006 (UTC)
LOL so the worst is yet to come ... Ideogram 03:03, 6 June 2006 (UTC)
Not necessarily on this article. But LotLE is right, there are plenty of ongoing disputes on WP. Take a look at the history and talk pages for Muhammad ibn Musa al-Khwarizmi sometime... --Allan McInnes (talk) 03:22, 6 June 2006 (UTC)
I prefer to stick to technical matters. Ideogram 03:26, 6 June 2006 (UTC)

Medcabal has responded. Ideogram 09:53, 8 June 2006 (UTC)

[edit] Standard Library

The advice to new wikipedians is be bold, and in this area I have actual expertise, so I was.

It was labelled as a stub that needed work, so I had a go. Assuming it to be outside the realm of prior recent edit wars. On looking at it in context it now has more words than it should, and so implies excessive importance relative to other ideas on the page. Perhaps they are needed, (the idea is inherently complex as it being part of a language is a bit fuzzy), perhaps all the words are not. Being my words I cant tell. Feel free to 'fix' it, radically. AccurateOne 05:58, 6 June 2006 (UTC) BTW the talk page is large, zen needs to fix it.

I don't think standard libraries are suposed to provide platform specific implementation. Thats the job of the interpreter. Stdlibs contain commonly used objects, etc, so programers don't have to do them themselves. Ex: Java. Jaxad0127 06:07, 6 June 2006 (UTC)
I was also bold and condensed it pretty strongly. Some of the stuff I cut out (such as some of the references to encapsulation) seems better suited to the standard library article. I also removed some of the stuff that either seemed technically inaccurate or too subjective (though I'm not certain that I fully avoided those traps myself!). If you think something I removed is vital for this article (as opposed to the standard library), feel free to re-introduce it. Hopefully I didn't over-condense. – Zawersh 06:44, 6 June 2006 (UTC)
I thought I had responded here, but thanks you removed the right stuff. I have now removed the secstub tag as presumably it isnt now. AccurateOne 08:07, 10 June 2006 (UTC)

[edit] "Purpose" discussion

Derek farn, if you still want to discuss this, we can pick it up here.

The current "purpose" section covers these points:

  • Programming languages facilitate communication
  • Programming languages are different from natural languages
  • Programming languages are executable
  • Many languages are needed for different contexts
  • Programming languages have become higher level

Which subtopics do not belong here? Ideogram 09:55, 8 June 2006 (UTC)

Whoops -- see comments above, please? kraemer 03:46, 14 June 2006 (UTC)

[edit] design philosophy

It seems to me this subsection doesn't say anything, and should be either expanded or deleted. Ideogram 11:11, 8 June 2006 (UTC)

[edit] blorped about APL

I just blorped a response to the APL question above. Yes, there are some typos I'm not going to fix. Mutatis mutandi. As I was grappling with how to best spin the significance of APL in its era, it finally occurred to me that a hugely overlooked perspective on the history of language design is the embedding forces imposed by a difficult work environment: paper cards, 100 baud teletypes, compilers trying to run in 64KB of memory, lack of lowercase letter forms, etc etc. Languages are not designed solely for expressive power. Much of the syntax of the C language was shaped by the requirement for a one-pass compilation process, and that influence remains with us everywhere. The casualty in one-pass compilation frameworks is effective error reporting. When you misspell a keyword in Google, it suggests alternate spellings. Our compilers could easily do the same if the compilation model worked by downward refinement. By now it is built into our genes that diagnosing a failed compile is a process akin to diagnosing a train derailment. A human reader will can look at your code, without hardly any understanding of your problem domain and suggest "it looks like you forgot to declare the variable i as an integer". Yet our compiler tradition is so rigidly front-to-back in their lexical analysis, they utterly lack the barest modicum of an overhead vantage point. Maybe it had to be that way for deeper reasons. In pactice, however, those decisions were originally reached to conserve scarce operational resources, and it now persists more by tradition than conscious design. I was reading pages about the origins of human languages (anthro-linguistics) and in that world, certain formative forces are clearly declared: this language was written on wood with a horizontal grain, so no letter element is a horizontal groove (which might split the wood). Cuniform letter forms are extremely different from ink and brush letter forms; parchment vs paper also had a strong influence. Our punch cards, 110 baud teletypes, 1200 baud glass consoles, etc. have had no lessor influence on language design than stone tables or the ink absorption properties of dried goat hide. If you are writing with a chisel, you soon invent APL. MaxEnt

Retrieved from "http://en.wikipedia.org../../../p/r/o/Talk%7EProgramming_language_Archive_2_d083.html"