Talk:Programming language

Contents

1 Humans or machines? 2 language links 3 Possible prejudices re: "mainstream" languages 4 Total rewrite 4.1 Rewrite of k.lee 4.2 Removed from subject page: 5 Numbers of Users? 6 Naming conventions? 7 Proper classification of Python 8 Miscellany 9 Turing completeness and generality 10 Cut from "History of..." 11 Writing From Scratch

Humans or machines?

I think we need to point out that programming languages, like other languages, are for humans to express human ideas in. The unique thing about programming languages is that we can automatically translate these expressions into the ones and zeros that computers use. Still, the primary purpose that should be stressed is that these are human languages, for humans to express solutions in which are meant to be understandable by other humans. Since most of the cost of software across the useful lifespan of a program is invested in enhancements and maintenance, the human-readability of programs is much more important than their nature as a "technique for expressing instructions to a computer".

Low-level languages such as machine code are also programming languages. All programming languages are in principle both human- and machine-readable, but the relative emphasis varies.

I agree, the importance of producing code that can be easily understood by a human is of extremely important and must be mentioned prominently in this article. Indeed, producing readable code that other humans (and not merely computers) can easily understand is one of the hallmarks of a good programmer. But - this is accomplished mostly through adding comments in a natural human language to the source at key points, and mostly not through the direct use of the programming language itself.

The original and still primary purpose of a computer programming language is not communication with other humans. A programming language is not a human language in the oridnary sense of the term; even two hardcore professional programmers don't ever go to lunch and talk to each other in Java or C. Natural human languages are far better suited to interpersonal communication. Programming languages were invented for and are used nearly exclusively for the express purpose of allowing humans to easily communicate instructions to computers (and later be able to easily modify those instructions), and not for human-to-human communication. Even programming manuals frequently express algorithms as human language influenced pseudocode rather than in a real programming language.

It's perfectly possible (and regrettably common) to write huge complex blocks of code or even entire applications that are unintelligible to anyone but the author, yet which work perfectly well when executed by a computer. A programming language is basically and fundamentally a "technique for expressing instructions to a computer." Doing so in a human-readable fashion is a big plus, of course, but it is not the fundamental purpose of a programming language, and is usually accomplished through appropriately garnishing the code with comments in some natural human language. Kwertii 09:38, 9 May 2004 (UTC)

FWIW, I am a programming language theorist and I would define "programming language" formally in the following manner: a programming language is a decidable formal language equipped with a Turing-complete semantics; a program is a programming language together with a member of that language. (BTW, the page for "Turing-complete" is not really, er, adequate...) This means that a language is a set of finitary strings, for which it is computable whether or not a given string belongs to it, together with a computationally adequate model, for example a mapping from each such string to a λ-term, or Turing tape, or partial recursive numeric function. In my opinion, few programming language researchers would disagree with this definition as applied to formal work. However, if you want to define the popular notion of "programming language" then, yes, you might want to add fuzzy conditions like "human-readable" and so on, and maybe weaken the Turing-completeness condition to admit terminating languages like Charity. -- [Frank Atanassow (http://www.cs.uu.nl/~franka)], 24 July 2004

That formal definition is too constraining. It would be a rather odd definition of "programming language" that did not count the simply-typed lambda calculus as a programming language. Conversely, I had a colleague working on a language with an undecidable type system. (The subtyping constraints were flexible enough to allow the user to encode Prolog programs in them.) He had proposed various restrictions to make the type system decidable, but it seems clear to me that his language didn't become a "programming language" only when he imposed those restrictions. So a programming language need not have a Turing-complete semantics, nor must it be a decidable formal language. k.lee 23:09, 25 Jul 2004 (UTC)

And conversely, to determine which is more "primary" or "important"--which is worse, a programming language that humans can't read, or one computers can't read? "Most of the cost of software across the useful lifespan of a program" may be in enhancements and maintenance, but if the program weren't machine-readable, its "useful lifespan" would be zero. --Daniel.

A programming language that humans can't read is clearly worse. There are plenty of useful programs that are not machine-readable. Virtually all work by academic programming language designers begins with the development of "core" languages, which are mathematical constructs first and foremost. The call-by-name lambda calculus is hardly primarily a tool for communicating with computers (if by "computers" you mean those beeping chunks of silicon that sit on people's desks). I find this this machine-oriented focus kind of disheartening. Do we not agree with the Dijkstra quote concerning astronomy and telescopes at the top of the computer science article?

"plenty of useful programs that are not machine-readable"--and similarly there are plenty of useful programs that are barely human-readable. That's not a good test.

There is a big difference between "not" and "barely". k.lee 23:09, 25 Jul 2004 (UTC)

The test I have in mind is:

-Examine the total amount of resources that humans have put into designing, studying, and using programming languages. (Or, if you like, examine the returns on that investment.)

-What portion of that investment would have been made, and what portion of those returns would have been received, if no programming language had been machine-readable? I think 3% for both would be a wild overestimate.

-What portion of that investment would have been made, and what portion of those returns would have been received, if no programming language had been more human-readable than, say, FORTRAN? I'd guess 70% of the investment and 20% of the returns, anyway...given how badly even readable programming languages are typically used.

The exact numbers are obviously arguable, but that's the test I had in mind. I agree with Dijkstra, but what computer science is about, and what programming languages are for, are two different things. Computer science is not about machines, but programming languages are for controlling machines, first and foremost; if they could not be used for that they would be relegated to a smallish sub-discipline of mathematics, neither very popular nor very well-funded.

-Daniel.

FORTRAN is already tremendously human-readable, compared to binary machine code or any number of encodings that would be adequate to the purpose of describing computation to machines. Furthermore, I don't see too much programming language research on making languages easier to read by machines. So this argument actually demonstrates the opposite of what you intended it to. k.lee 23:09, 25 Jul 2004 (UTC)

Lastly, Kwertii's comments strike me as unconvincing:

• It is irrelevant that programmers don't speak to each other in Java. Musicians don't speak to each other in musical notation. Mathematicians don't speak to each other in pure set theory and first-order logic. (Admittedly, some of them come close.) Lawyers do not speak to each other purely in legalese. Sculpters do not speak to each other with a series of little statuettes. There are other forms of human-to-human communication besides the oral use of natural language. Programming languages are one of them.
• Furthermore, although programs can be written that are often called "unreadable", they are not literally unreadable, merely difficult to read. Nor should we construe the existence of hard to read programs as evidence that the primary purpose of programming languages is to communicate with machines. The English translation of Jacques Derrida's On Grammatology is nigh unreadable, but that does not show that deconstructionist literary theory is not a form of human-to-human communication.
• It is certainly not the case that programmers communicate with other programmers primarily through comments! In fact, natural language comments are a noriously bad way to communicate precisely about a program. Code itself is the major form of programmer-to-programmer communication. (See the amicus curiae brief in MPAA v. 2600 (http://www-2.cs.cmu.edu/~dst/DeCSS/amicus-brief.html), which argues a similar point.)
• Finally, as for Kwertii's claim that the "original" purpose of programming languages was to communicate with machines --- programming languages predate executable programming language implementations by at least two decades. The lambda calculus was invented in the 1930's. FORTRAN was invented in the 1950's. k.lee 09:24, 20 May 2004 (UTC)

Make that one decade. The codes given to some of the first computers in the 1940's, via paper tape and the like, certainly count as programming languages, and were designed to control machines. For that matter, Babbage's punch cards were designed to control machines.

-Daniel.

Augusta Ada Byron King, Countess of Lovelace, born December 10th 1813 ... invented the first computer programming language. -- Wiki:AugustaAdaByron. I'm not sure which side of the argument this factoid supports.

---

producing readable code that other humans (and not merely computers) can easily understand is one of the hallmarks of a good programmer. But - this is accomplished mostly through adding comments in a natural human language to the source at key points, and mostly not through the direct use of the programming language itself.

Many people believe this. Quite a few programmers disagree very, very strongly. We believe that producing readable code is mostly through renaming, refactoring, etc. so that the name of an variable communicates (to humans) what it is, the name of a method communicates (to humans) what it does, etc.

See Wiki:TreatCommentsWithSuspicion, Wiki:ToNeedComments ("Refactor the code properly and you won't need comments.")

-- DavidCary 23:36, 5 Jul 2004 (UTC)

As computers grow more complex, our ability to translate solutions into executable binary has become more abstract, enabling us to express solutions in terms of objects, templates, patterns and aspects. Such abstractions enable a more natural translation from human needs, often expressed as "use cases", into executable solutions. It is this trend toward greater abstraction in the expression of programming solutions that enables programmer productivity to double, despite programmers being locked into fixed biological hardware.

If we gaze deep into the crystal ball, we see the logical extension of this trend as computers that are capable of conversing with humans and creating executable binary programs from desires or solutions expressed in pure human language. The shift away from computer-centric aspects of programming languages toward more human-solution-centric aspects will continue to be the defining characteristic of near-future programming languages.

The "holy grail" of programming language development from this viewpoint would be the creation of a transparent interface to a computing substrate that can extract requirements from the user and instantiate an executable solution. Of course, at this level of abstraction, there is no "programming language" any longer, merely a somewhat pedantic conversation required to define the essential complexity of the problem the user wishes to solve.

At any rate, some mention should be made of this shift from computer-centric aspects toward human-centric aspects and how this affects programmer productivity and how it will shape the role of programming languages going forward.

language links

(moved to Talk:List_of_programming_languages)

Possible prejudices re: "mainstream" languages

This article seems to be written largely from the point of view of a programmer in mainstream languages. For example, interactive use is attributed to interpreters, without considering that eg. many Smalltalk and Lisp systems have native compilers that are used interactively. Sorry for not bothering to work this rant into a considered and balanced edit of the article.

-- han

I disagree. I don't think we need to perpetuate the prejudices of "programmers in mainstream languages" (read C/C++, Java). That would be about as stupid as rewriting the operating systems entry from the point of view of a windows user.

Anyways, someone who has a copy of 'Programming Language Concepts and Paradigms' handy, an exceedingly comprehensible book on the subject, should rewrite this article. -- Ark

Total rewrite

This entire section needs to be rewritten from scratch. This includes this topic plus those for the various languages and language concept articles. This is going to be a big project but I think its important. Computer programming is too much a part of modern life to be half covered in an encyclopedia so I have to agree with Ark. Rlee0001 05:25 Jul 27, 2002 (PDT)

On another note: I would limit the list of programming languages here to just the main languages and not all the dialects. For example, there are something like 15-20 dialects of BASIC listed in the BASIC programming language page. Instead of listing all of them, one link for the entire language would suffice. If the user want's a dialect, he/she can stiff get to it from the BASIC page. Same goes for all the languages. Further, I fail to see why people are listing such obscure languages and dialects in an encyclopedia. Some languages have historical or technological significance. Others are just current brandnames for half-written freeware with a source forge page and no user base. Should "Applesoft BASIC" really get its own topic? What did it do to revolutionize the language? Did it have a particularly large user base? Did it establish any conventions which are widely in use today? If not its probably not worthy of its own topic. Even worse is articles like ibasic. This is a basic interpreter for the mac. It has no historical significance: it was just created within the last year by an ameture developer who lives in some small cottage in sweden somewhere. It gets it's own encyclopedia article? Rlee0001

I would propose the following:

• Make a (short) list of the most significant programming languages in history to put on the Programming language page. Annotate the list to make clear just why these language are mentioned.
• Make new article called List of programming languages, where every single progamming language can be mentioned, even dialects. This page can have several different orders, such as alphabetical, but also by type (functional, OO, etc.) or maybe even a history tree (there's a good book about the history of Programming Language by Sebasta, if I'm right, you may use that as a reference).
• For those dialects/spin-offs/implementations/ports of programming languages that are never going to be more than a single-sentence article: assemble on the page of the main article (BASIC programming language here) and make a section where you mention this or, when this is getting a long list, make it a separate article.

That's what I think would be best. I'll try and see if I can help you with some of the work you're proposing to do; there are enough other people with knowledge about the subject around, so it should be possible to get something good out of this. Jeronimo 01:56 Jul 29, 2002 (PDT)

---

BTW re: classifying languages by category, many languages belong in more than one category (constraint languages vs. rule-based languages vs. logic languages; and what about functional + OO languages like CLOS?) Just to keep in mind. --k.lee

Rewrite of k.lee

FYI: For some time I've been working on a ground-up rewrite of this article, because its current state does not make me happy. It's not ready to go live, but I've finally posted my current draft in my user space. I welcome comment on my rewrite; also feel free to edit it directly. It's taking me a long time to do the rewrite, but I plan to replace the entire current article eventually. k.lee 02:28, 27 Aug 2003 (UTC)

The link seems to be broken. -- P3d0 11:05, 27 Aug 2003 (UTC)

It appears to me as a red "edit" link rather than a regular blue link. -- P3d0 21:49, 28 Aug 2003 (UTC)

is there a reason that javascript isn't mention in the " Commonly Used Languages"? Also the link is red for me too ... reddi 21:58, 28 Aug 2003 (UTC)

Ok, the link works now. -- P3d0 00:03, 1 Sep 2003 (UTC)

I'm not sure I like the rewrite. I haven't read the original to compare it, but the rewrite seems to be at a very awkward level of detail. Anyone with enough background in the area to understand that writeup presumably doesn't need to read it. For instance, the grammar example casually uses the terms "atom" and "symbol" which have very little meaning to those outside the field of computer programming. In fact, the whole section on grammars would be better off in another article (say, on parsing). -- P3d0 00:10, 1 Sep 2003 (UTC)

Actually, I think that when I get to editing this article some more, I'll factor out several sections (e.g., the history of programming languages, and language semantics) into separate articles. I'll keep your suggestion in mind. k.lee 02:07, 2 Sep 2003 (UTC)

---

The link seems to be working now. :-)

I would like to ask is there a clear concensus that the original article is unsatisfactory to the extent that it needs a re-write? TonyClarke 11:38, 27 Aug 2003 (UTC)

Well, I don't know about a consensus, but here are my reasons for wanting to rewrite the article. First, the original article is rather disorganized. Second, it leaps into issues like the representation of data without even saying why programming languages exist in terms that a layperson can understand. Third, the original article does not maintain a sufficient distinction between the design of programming languages and their implementation. Fourth, the article does not give enough attention to formal languages (actually, if you counted all the programming languages ever invented, I suspect formal languages would outnumber "practical" languages). Finally, and most importantly, as the poster at the top of this talk page noted, the article does not give priority to a programming language's role in human-to-human communication --- which all language designers and software engineering researchers, not to mention most working programmers, understand as its most important role. It's possible that you could alter the original article to fix these flaws, but the changes would be radical enough to resemble a ground-up rewrite anyway. BTW I have reused sections from the original article where I thought appropriate. k.lee 02:07, 2 Sep 2003 (UTC)

---

The current main page definitely needs to be re-considered. While it is quite accurate (it seems to me), it is mostly a summary of the topic using the terminology of the discipline, and so is quite inscrutable to a newcomer. It occurs to me that an encyclopedia needs both a specialist and non-specialist version of the general information articles. The specialists need a means to agree on the theoretical structure of the topic, and the newcomers need to learn about it from scratch.

Removed from subject page:

To Do: this is just an outline to get started; add some descriptive text (or put in '/' links) and add a few representative languages to the descriptions

• sequence of execution
  • procedural, sequential, linear
  • event-driven
  • pseudo-random
• method of execution
  • interpreted
  • compiled
  • hybrid
• main programming paradigm
  • procedural programming
  • structured programming
  • object-oriented programming
  • functional programming
  • aspect oriented programming
  • logical programming
  • distributed programming
• primary method of use
  • script, shell, command
  • macro, text processing
  • application
  • systems programming
• abstraction level
  • visual programming and integrated development environments
  • 1GL (First Generation Languages)
  • 2GL (Second Generation Languages)
  • 3GL (Third Generation Languages)
  • 4GL (Fourth Generation Languages)
  • database UI development kits
  • high-level (declarative, objective, procedural)
  • assembly
  • machine
  • microcode
• other
  • pathological
    • Turing tarpits
  • specialty

---

Rlee0001 01:51 Oct 20, 2002 (UTC)

Numbers of Users?

Do Ruby and Scheme really have several hundred thousand users, as in programmers who use them regularly? I doubt it, but I've been wrong before. Wesley

I believe so. But no one can prove either point anyway. --TakuyaMurata

Naming conventions?

Hi,

why have we put virtually every programming language on "Foo programming language", and not on "Foo" if "Foo" is reasonably unique? "Programming language" is disambiguation, and that should only be used when there is ambiguity, should it not? --Eloquence 00:08 Jan 24, 2003 (UTC)

Please see Wikipedia talk:Naming conventions (languages). There's no counterargument against changing to a sensible naming scheme that I'm aware of other than that certain people seemed to take it as a personal affront when it has been suggested in the past. --Brion 00:12 Jan 24, 2003 (UTC)

Heck, I'd forgotten about that. The convention as stated at Wikipedia:Naming conventions does now say not to add "programming language" if the name of the language is unique, but I've not done any work in moving pages to reflect this new convention yet. I don't have time to start on this right now, but now that I've been reminded about it, I'll get to it when I have time (others, of course, are more than welcome - indeed encouraged, nay begged - to get there before me). --Camembert

Great. I'll start some moving, although fixing double redirs will be an annoyance and we'll probably lose some page histories .. --Eloquence 00:19 Jan 24, 2003 (UTC)

---

Proper classification of Python

Some people including me might take exception to Python being classified as procedural with bolt-on OO technology, this has been extensively discussed in the Python community (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&group=comp.lang.python)

Miscellany

I would like to point out that the programming language list above misses Objective-C. Brent Gulanowski 15:54, 15 Oct 2003 (UTC)

Turing completeness and generality

One thing the article appears to miss is the basic elements that all languages must share to be able to express any computable algorithm. I was taught this as "Sequence, Selection, Repetition" but it may be known in a number of ways. I feel this is important, as well as correct attribution to whoever proved it mathematically - was it Turing maybe? I feel that once it is clear that all languages must support this basic elements, then they can be discussed in the abstract without having to say language X has this feature, language Y has this feature, etc. (though that can be added as an extension). GRAHAMUK 23:29, 9 Nov 2003 (UTC)

I agree that it would be very nice if the article has discussion for foundmental aspects of programming language. Particularly I would like to see what makes programming language real languages. What distinguishes them from markup languages like HTML. I am not sure about Sequence, Selection, Repetition. I believe the most basic elements of languages are control and data abstraction. This theory fits to the explanation of assembly language very well. Assembly language supports jump and conditional jump, very primitive form of control abstraction. It also supports labeling, primitive form of data abstraction.

Also I think that the article is too much devoted to discussion for data type and data structures. Is it so important to mention strong typed or dynamic type checking since datatype article covers such adequately. And control flow on the other hand has very few. Don't we have to even mention if or while? -- Taku 05:34, Nov 11, 2003 (UTC)

Sequence/selection/repetition is far more fundamental to the concept of a programming language than data or control abstraction. I'm not saying that a language with only those features would be a good language, but I am saying that without those features it would not be a programming language at all. See brainfuck - it's a perfectly valid programming language, any computable problem can be expressed in it - it's just not a good one for expressing human ideas. It's at that second level that abstractions are important, but these are building on the fundamental requirement for stepwise execution, decision branches and loops. Incidentally assembly languages are possible without the features you mention, yet still remain valid languages. I can remember using a (poor) 6502 assembler on the commodore 64 that did not have labels - you had to specify branches using line numbers. But it did work. GRAHAMUK 06:28, 11 Nov 2003 (UTC)

Thinking about this further, this is precisely what separates programming languages from markup languages. I'm not familiar with the full extent of HTML, but as far as I know it lacks the ability to perform branches based on conditions, or the ability to perform repeats. Also, talking of assembly language, it is possible in theory to design a serial processor with only one instruction - "subtract and branch if negative", yet such a processor could still implement any known algorithm, because it obeys the fundamental requirement of seq/sel/rep. This is pretty close to the idea of brainfuck in hardware. I sometimes wonder if such a processor, despite lacking, well, anything much really, could be made to go so fast that it would still be actually pretty good on performance. You could also make it massively pipelined. The ultimate RISC machine... Anyway, I digress, but the point is made, I think. See also turing complete. GRAHAMUK 06:41, 11 Nov 2003 (UTC)

Umm, very interesting. I think you are talking about what an minimum requirement to make the language capable of simulating the Turing machine. And probably the three criteria Sequence, Selection, Repetition are right. I was thinking like programming language as the mean of abstraction. The Turing machine is the most powerful computer we know today and we don't need any programming languages or such to perform computable algorithms. Programming languages were in my view needed and then invented because human beings need something abstract to make programming easier. Mnemonics in assembly languages are completely meaningless to the computer but are only to we human. This is why I claimed data and code abstraction are basic elements of programming language.

But you are right. Brainfuck is considered as programming language generally, if it misses my picture of programming languages. SImilar small languages like PostScript are also among them. In other words, programming languages are not only for human or are they? -- Taku 06:40, Nov 13, 2003 (UTC)

-- Taku 06:40, Nov 13, 2003 (UTC)

Is "sequence/selection/repetition" what they're teaching the kiddies nowadays? :-) Functional programming folks might prefer to say it's abstraction/evaluation/recursion. Turing equivalence can't be used as a precise criterion, because for instance it assumes infinite storage, and classic Fortran requires fixed-size allocation, yet few would say it's not a programming language. I would call Turing-equivalent languages "general-purpose programming languages", while leaving "programming language" as a more general moniker for any linguistic form of expression that instructs a computer, irrespective of generality. Stan 08:23, 13 Nov 2003 (UTC)

"Sequence, selection, and repetition" are not enough to make a language Turing-complete. A finite-state automaton is capable of all of the above (which correspond to the concatenation, union, and Kleene star operator of regular languages). You also need arbitrary memory allocation (or infinite storage, which is the same thing).

Also, Stan's point re: FORTRAN is a good one. The primary distinction between markup and programming languages is one of emphasis. They overlap --- any Turing-complete markup language (e.g., LaTeX) can also be considered a programming language --- but "everyone knows" when something is primarily a programming language or a markup language.

Finally, it's pretty obvious that any non-joke programming language is intended primarily for human consumption. Joke languages like Brainfuck or Unlambda are simply exceptions that prove the rule --- they're designed by humans for human amusement. k.lee 05:27, 17 Nov 2003 (UTC)

Actually Stan I have no idea what they are teaching the "kiddies" these days as you so dismissively put it. I actually picked up the seq/sel/rep thing from a course I did many years ago which was an introduction to microprocessor design. The point was emphasised that as long as the hardware provided these things, then it could run any software "language", and therefore all programming languages mapped to these fundamental concepts at their heart. This stayed with me so it must have made some sort of good sense to me at the time. Now, it's quite likely that from a software perspective, some of these things may be self evident - for example, the fact that each statement of a language is executed in written order and thus one thing logically follows another (Sequence). Programmers take that for granted (though obviously CPU designers need to construct a mechanism to make it happen), so maybe it doesn't need to be stated - but we must write for the proper audience here.

Too bad that they take it for granted :-) What you say is valid for procedural languages, but absolutely not for declarative ones. In Prolog language, you state the set of "rules of inference". The burden of setting the order of their application is onto compiler. Once you see what I mean, it is easies to agree that HTML and TEX are as good a programming language in a sense that they make the computer do what I want. The "magic triads" abstraction/evaluation/recursion, sequence/selection/repetition, encapsulation/.../... are woodoo talk for specific approaches, important for sure, but they must be discussed where they fit. When speaking about PL in general, one must have a broader POV. Read more good SF, folks :-)Mikkalai

That audience is not other programmers - they know this stuff already -, it is the "intelligent layman" who may not realise that that's the case. Without some proper foundations, the abstraction/evaluation/recursion thing is still too "high concept". Another example I clearly remember from my own early steps with programming (I've been a professional programmer for 20 years, so it's a while ago!) is parameter passing - programmers take for granted that parameters map from caller to callee based on the position of the parameter in a list, but I can remember thinking how error prone that seemed - back then I thought it would be better to "find" the parameter based on its name and ignore its position. Of course knowing now how a CPU actually implements a subroutine, the "position" thing is clearly far more efficient and sensible, and there are likely other undesirable side effects that name binding might have. The point to make here is that to the uninitiated, what seems obvious to a programmer may not be at all obvious to someone else, so starting with implicit fundamentals in order to eliminate any misunderstandings seems a good way to go with an article such as this. Given this approach, I'm not sure that referring to Turing completeness is even a good idea - is the intelligent layman that bothered about the mathematics? I suspect most people coming to WP are looking for a solid, precise but not necessarily complete discussion of the subject. If it grabs them sufficiently, they can look into the maths further if they want. GRAHAMUK 12:05, 18 Nov 2003 (UTC)

People learn positional parameter passing in junior high school algebra: if f(x, y) = 3x + 4y, then f(1,2) = 11. It's true that a function in a programming language is not the same thing as a function in pure math, but the notation ought to be familiar enough. It's only because (a) programming is usually taught at such a low, machine-oriented level and (b) math is usually taught badly, period, that so many programmers find the "high-concept" explanation less intuitive. To the educated layperson, who has not been forced into low-level thinking by a typical CS curriculum, abstraction and application may well be as easy to explain as branching and looping. The experiences of the PLT Scheme folks suggest that Scheme (which is, basically, the call-by-value lambda calculus) is easier to teach to undergraduates than C or Java. The only undergraduates who struggle with Scheme are those who learned bad hackery in C in high school, and convinced themselves that this was the only way to program. If we're targeting the article towards laypeople, then there's no reason to avoid conceptual explanations in favor of a machine-oriented explanation.

Also, a Wikipedia article should be as complete as the contributors can make it. If the article grows too long, then it should have a quick summary at the top of the article, followed by the more in-depth discussion; or else it should be broken into sub-articles. But there's no reason to leave something out if it's an important concept, simply because it requires more effort on the part of the reader to grasp.

P.S. Minor pedantic point: you don't need recursion in order to be Turing complete. Abstraction and application suffice; you can build recursion out of abstraction and application, as with the pure lambda calculus's y-combinator. k.lee 18:15, 18 Nov 2003 (UTC)

Hey, I added the ":-)" to indicate clearly that the "kiddie" remark was in jest, oh well. Although I'm probably the most formally qualified WP editor for this article (PhD in languages and all that), my first step would be to learn from my predecessors - review the current EB/Encarta/etc writeups, plus reread the intro sections to the best textbooks, both those aimed at specialists and those aimed at nonspecialists - and get an idea of the strategy that others have used. Since encyclopedias are reference works, there is a certain falloff; everybody reads the first sentence, 50% read the second also, 10% get to the second paragraph, and so forth, with only the deeply interested lasting all the way to the end of the article; so you generally want to transition gradually from generalities ("language is how we tell a computer what to do") to Church-Turing, which has to be mentioned eventually, because it's one of the bases that justify some of our classification of types of languages. Stan 18:43, 18 Nov 2003 (UTC)

I agree about the structure 100% - far too many WP articles dive in with no context establishing stuff up front. I suppose the rest of it comes down to whether we approach languages bottom-up or top-down. I can see advantages to both approaches. Since I came from a hardware background, bottom-up seemed to work well for me, going from boolean algebra to logic gates to registers to CPU architecture to stored programs to machine code blah blah etc. Other readers will respond better to the top-down approach, going from "high concepts" of languages towards the underlying bits and bytes. Perhaps both approaches need integrating in the article by including two sections. I'm presuming that the top-down approach is preferred by most teachers of the subject these days, but one thing I do notice is that as a result few people (who are not programmers but nevertheless are expected to know the basic principles) cannot understand or make the mental leap from the language to the chips that implement it in hardware. I've read a lot of vague handwaving arguments to explain it recently while marking some student work at the local uni, so perhaps I've just got a bee in my bonnet about bridging the software/hardware divide in a sensible, clear manner. GRAHAMUK 22:29, 18 Nov 2003 (UTC)

The hardware/software divide should get its own article I think; tricky to explain but worth trying. You could maybe do it as a sort of slice across other articles, xref'ing if the reader doesn't know a particular term. Something like "global = 1;" -> "ld r2,1; st global,r2" -> memory-mapped device -> electricity flowing -> light bulb turning on. If you stuck to the "what" and "how", and leave out the "why", it could be both succinct and illuminating. Stan 08:15, 19 Nov 2003 (UTC)

I know you guys know much about programming languages and theories in computer science than I do but I was wondering how about historical approach. RISC is a very good article. Although I don't have much expertise in hardware, the article makes a lot of sense to me. The nice thing is that it doesn't know give particular examples of RISC like a list of instruction code but it focuses on why computer science comes up with the idea of RISC in historical and technical context and also gives a plenty of practical examples of architectures. I think the same strategy can be applied to this article. In some ways, the article simply gives a summary of concepts which really doesn't make sense unless you know it before and sometimes goes to too much detailed. For example, I don't see why it is so important to spend a lot of space to discuss type system while some important concepts such as lazy evalution, side effects and referentical transparency are completely omited.

As I keep repeating, I think it is very important to avoid the article is like a textbook. RISC article is completely useless if you want to learn an assembly language and how to make a code generator for RISC architectures. Let alone Wikibook for such case. Well, just a thought. I am just hoping I am any help at all. -- Taku 07:15, Nov 19, 2003 (UTC)

Yes, a bit of historical recapitulation is helpful, especially to motivate why there are different languages. This article can't really get much into specific concepts like lazy evaluation though, those have to be pushed to language semantics articles so as to keep the top-level article readable by laypeople. Stan 08:15, 19 Nov 2003 (UTC)

You would not expect to learn an assembly language or how to make a code generator for RISC architectures from Wikipedia. You would get that from a text book! So which is it to be? To my mind, the RISC article is actually a very good encyclopedia article. GRAHAMUK 09:40, 20 Nov 2003 (UTC)

Umm, can we have a slight summary of different programming paradigms? I think it is important to show that why we have come to have several languages and what is difference between them. I am not suggesting to have complete discussion of specific topics like lazy evaluation but I don't know how to put, more like how different languages approach the problem of programming in different ways. I think such discussion can have the article more focused on making sense to the general public about what programming is like. The imperative approach is not only one and surprisingly many even computer programmers know little about how problems are done in programming with many different ways. Many people just learn how to do programming in a particular language like C or LISP and not sure programming language as general. For example, I think it would be nice to see how to reverse a string in many ways as an example. While it is very unnecessary to discuss how arguments are passed or how type system works. The bottom line is that the article must not be a summary of programming languages topics, but should discuss actual problems. I know it is easy to say and hard to achive, just chating about my idealistic view. -- Taku 08:40, Nov 20, 2003 (UTC)

I agree that there should be some explanation for why there are many languages - this itself shows that there is no one, true way to program. However, I'm not sure about examples, at least not in this article. There could be a link to a separate article listing the same program in all the various languages if you wanted. The problem is that including examples here of string reversal (or whatever) is EXACTLY turning it into a text book. The article should be about languages, not a tutorial for any particular one (or all of them). Seems to me your suggestions lean more towards the textbook approach, despite declaring that you don't want WP to be one. GRAHAMUK 09:52, 20 Nov 2003 (UTC)

Well, it shows that we have not yet found any one, true way to program. -P3d0 15:40, 20 Nov 2003 (UTC)

I agree with Taku -- if you think something is "too much" for an encyclopedia article, please move it to one of the Wiki Books http://en.wikibooks.org/wiki/IT_bookshelf --DavidCary 15:36, 26 Jul 2004 (UTC)

---

(moved to User talk:Dysprosia)

Cut from "History of..."

The following piece is cut out of section "History of programming languages".

<<<

As the cost of computers has dropped significantly and the complexity of computer programs has increased dramatically, development time is now seen as a more costly consideration than computer time.

Newer integrated, visual development environments have brought clear progress. They have reduced expenditure of time, money (and nerves). Regions of the screen that control the program can often be arranged interactively. Code fragments can be invoked just by clicking on a control. The work is also eased by prefabricated components and software libraries with re-usable code, primarily object-oriented.

Object-oriented methodology was introduced to reduce the complexity of programs, making code easier to write and to maintain. However, some argue that programs have, despite this, continued to increase in complexity. Recent languages are emphasising new features, like meta classes, mix-ins, delegation, program patterns and aspects.

See programming paradigm

>>>

All the above is true, but... This rant is good for a pop-sci article in an online magazine, but not for encyclopedia: chaotic, no *history*, and no *programming languages* Mikkalai 00:37, 13 Dec 2003 (UTC)

---

"Computer language" is not synonymous with "programming language". A programming language is a computer language used for programming.-P3d0 00:14, 2 Jan 2004 (UTC)

Writing From Scratch

This Section Programming Language needs a total wash and be written from scracth. I volunteer myslef to devote some time to it. As I am new to this site and I am learning how to edit things so this section will be online within a week and with a new style yana209 22:01, Jun 22, 2004 (UTC)

---

Some languages such as MUMPS and is called dynamic recompilation; emulators and other virtual machines exploit this technique for greater performance.

The clause before the semicolon isn't even complete. I'd fix it, but I'm not sure how exactly it should read. - Furrykef 15:17, 9 Sep 2004 (UTC)

fixed. Ancheta Wis 11:42, 29 Jan 2005 (UTC)