Talk:Pascal programming language

Could somebody fix the link to the GNU Pascal compiler please? --HJH

Fixed on Sep 2, 2002 by Jan Hidders

October 9, 2002 - I think the list of criticisms should probably be removed as it seems out of place and is no longer current. -- Jim

But it is of historical interest at least -- Error 03:40 8 Jul 2003 (UTC)

For this reason I move the detailed point of criticism to this talk page. The article as a whole is not yet fully developed. It talks nothing about data types, syntax etc, so if so much space is dedicated to criticism it makes a very unbalanced first impression. If there is more stuff written on the language the following should be moved back. --Hirzel 11:01 8 Jul 2003 (UTC)

The summary of Kernighan's criticism of early Pascal in that paper is as follows:

1. Since the size of an array is part of its type, the programmer can't create procedures that deal with general arrays, without regard to their size. This is particularly a problem for string handling.
2. The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality of a program - variables require much more scope than they ought to.
3. The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.
4. The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
5. The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
6. The 'case' statement is emasculated because there is no default clause.
7. The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.
8. The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
9. There is no way to override the type system, most notably, no casting.

As mentioned above, the currently available compilers address most of these issues.

Even if we accept that modern compilers extend the language to resolve the problems, his reasons are extremely dubious: either wrong or arbitrary. The sole valid arguments are the lack of separate compilation/modules (though units are a standard Pascal compiler feature, even if not part of standard Pascal) and the limited file access and complete lack of commandline-argument access (ditto). The only reason I mention it is that the main article and this page both take the assumption that all of the reasons are valid. Here's the list of the numbered reasons that aren't completely valid:

1. Conformant arrays are a part of the standard.

2. Static variables are a misfeature. There's usually a method that's more elegant and efficient to solve the problem.

3. This is actually a sloppy quirk in C, not a limitation in Pascal. Even C++, the successor to C, requires functions to be declared before they are used.

4. Technically true, but C only has a preprocessor that puts included files in the source. A Pascal programmer could do the same thing manually.

6. A "default clause" in a case statement is rarely needed, there are usually more elegant ways of acheiving the result. Besides, anyone who is defending something as awkward as the C switch syntax has no right to bash other languages' equivalents.

8. Correct, but that's the third time he mentioned it: see also 4 and 7. This is technically invalid since it's just upping the reason count.

9. Variant records and pointers are a way. Just because Pascal doesn't make it easy to shoot yourself in the foot doesn't mean that it's impossible.

[Scott A. Moore] For interest, here is my counterpoint to Kernighan:

For the points above:

1. This was Kernighans best point (and he says so, "this botch"...). Wirth had a point about "withholding the limits of an array from the compiler" J&W, but it carries theory over practicality. Alogol, Pascal predecessor, had variable arrays, and so did Wirth's own languages after Pascal, Modula and Oberon.

2. Absolutely disagree. Static variables, better known as globals, are in the language as much as they ought. The idea of a static placed in a function as a "pseudo local" would not be useful unless it were preinitalized, and preinitalizing variables in general takes code that ought to be visible to the programmer and hides it in the implementation. The C language must have two versions of statics, one the preinit copy, and one the actual variables, and copy one to the other, or let the user scribble over the preinit copy (which creates virtual memory copy on write and sharing issues).

3. Right, but wrongly blamed on one pass compilation. This is really part of 4 (separate compilation), and most modular compilers relax dec order.

4. Separate compilation. Absolutely C's biggest advantage. No argument.

5. Disagree. Having the user dictate the order of expression evaluation, even between operators that are otherwise associative, ties the hands of the optimizer. This is one of the worst features of C. It is true that it creates code difficulties with novices, for example "if (i < 10) and (a[i] = 2)" where the test for i is a valid index will fault because a[i] is executed regardless, is reformed as "if i < 10 then if a[i] = 2", etc.

6. No, having an "else" or "otherwise" addition to case makes the users OVERUSE the case statement by sticking many unrelated, or very sparse, cases into it that would be much better served by a string of "if" statements. Example:

case a of

 50:...
 102: ...
 else ...

end;

Does not acheive enough relationship between its cases to justify use of a case statement, which certainly implies to the compiler that it can optimize the case statement (with say, a tabled jump).

7. Absolutely correct. In fact, I believe I have traced most of Wirth's assumptions about file handling to the CDC 6400 series computer and the Scope OS that ran on it (see my site for more details). Scope didn't allow named files in its "local, active file" area that programs were forced to use, then the Scope command language was used to associate external, named files on the disk with those in the unnamed area. I believe that Wirth didn't like the idea of introducing named files into Pascal (since filenames were and are OS dependent), and so he essentially formalized Scope's methods into the language, but I believe it was a mistake.

8. This is really point 4 yet again. I now disagree that includes are the way to do that, but we have learned a lot about languages since C was created, so when Kernigan wrote the article, the comment was fair.

9. Abosolutely not. Casting at will has been a disaster for C, and now language designers are scrambling to try to fix it, with C# and Java.

See also Kernighan's "software tools in Pascal", where he clearly shows that he thought the "fix" for Pascal was to make it look like C :)

---

This article should include a "Hello, world!" example since most of the other programming language articles have one. —Frecklefoot 18:01, 8 Aug 2003 (UTC)

There is one for Pascal at the Hello world program Wikipedia article.

I added an Hello World example along with some syntax comments a couple days ago. Forgot to mention it here. Jim 21:14, 13 Aug 2003 (UTC)

Contents

1 Super Pascal and non-numeric lables 2 Origins of Pascal 3 Pascal vs C 4 Turbo Pascal 5 Edits 6 Pascal vs C

Super Pascal and non-numeric lables

The article says that "Super Pascal was a variant which added non-numeric labels, a return statement and expressions as names of types."

While I am not familiar with Super Pascal, Pascal's labels can only be non-numeric and have always been that way. I sense a possible confusion with dialects of BASIC, which did introduce non-numeric labels at some point.

The syntax definition of a label in the original Pascal was <unsigned integer> – an unsigned integer is numeric.[1] (http://pages.cpsc.ucalgary.ca/~becker/231/SyntaxDiagrams/pascal-syntax_files/frame.htm) -- RTC 17:55, 7 Jan 2005 (UTC)

Origins of Pascal

Removed text:

in an effort to make structured programming easier for a compiler to process

is quite wrong. These interests of Wirth came out of the Pascal project in fact. I met him at the Symposium of Programming Methodology and Compiler Design which my then employer, the Australian Atomic Energy Commission, organised in Sydney the mid-70s. He was the keynote speaker. We'd attracted him because we were distributing Pacsal 2000, then probably the best Pascal compiler available, which ran on IBM 360/370 mainframes and was based on Ikeda's trunk compiler. My personal contribution to it was to write (or rather rewrite) the installation JCL and instructions.

As he told it then, he'd designed PASCAL (as we than called it) as a paper-only language, to be learned by his students for on-paper exercises before going on to real languages. If this seems bizarre, remember that in 1970 we are talking about an age where CRT terminals were almost unknown outside the computer rooms of major computer installations. Students input their programs on coding sheets, punched cards, OMR sheets, or perhaps by teletype or other printing terminals, and most often received their listings back as printed outputs.

Wirth was amazed when someone, I forget his name, a professor in Holland he was, said he'd written a Pascal compiler! (Could have been Dijkstra? He was deeply involved in Algol at the time -- Marco van de Voort) But the language and its concepts never looked back. We had t-shirts with the words "Fortran makes it easy to write bad programs" screen printed on them. Ah, memories!

I'll try to find the symposium proceedings, I think I still have them, to flesh this section out a little. Andrewa 00:48, 13 Jul 2004 (UTC)

I thought I remembered reading that Wirth designed Pascal in part as a reaction against the bloatedness and creeping featuritis that he felt had infected ALGOL 68, and that Pascal was his own idea of what ALGOL 60 should have become. Does this ring any bells? -- Dominus 14:55, 12 Aug 2004 (UTC)

For example, in Pascal and its Successors (http://www.swissdelphicenter.ch/en/niklauswirth.php), Wirth says "Freed from the constraining influence of [the ALGOL committee's]] consensus, Wirth developped the language Pascal in Zurich. ... The programming language Pascal was designed in 1969 in the spirit of Algol 60 with a concisely defined syntax representing the paradigm of structured programming." -- Dominus 15:02, 12 Aug 2004 (UTC)

Pascal vs C

The article says, in part:

Another major difference [between Pascal and C] is that Pascal is strongly typed. This means that all variables must be defined with a specific type before they can be used. Also, incompatible variable assignments are not allowed without an explicit typecast. This prevents common errors where variables are used incorrectly because the type is unknown. It also alleviates the need for Hungarian notation—the practice of prefixing variable names with type-identifying letters.

This is nonsense, for several reasons:

1. "Is strongly typed" has no commonly agreed-upon meaning.
2. Assuming the definition given above, both Pascal and C are "strongly typed" and so this is not "a major difference" between the two languages.
3. In Pascal, incompatible variable assignments ar enot allowed at all, with or without "an explicit typecast"; Pascal has no explicit typecasting mechanism.
4. Since type declarations are required in C as well as in Pascal, it is impossible to use a variable incorrectly "because the type is unknown", so these sorts of errors are not "common". The author of the passage may have been thinking of some other common error, such as casting data to the wrong type or dereferencing pointers incorrectly.
5. The "need" for Hungarian notation is widely contested, but if there is such a need, it would appear to be just as valid in Pascal as in C.

I think this paragraph needs major alterations. In my view, the type system differences between Pascal and C have been greatly exaggerated. I know that many people disagree with me on this, so I don't want to alter the paragraph myself without getting some consensus first. But as it stands, the paragraph is not simply wrong, but absurdly wrong, and it must be changed. If I don't hear otherwise, I will remove it.

-- Dominus 14:53, 12 Aug 2004 (UTC)

I don't think it should be removed. Afaik C doesn't e.g. provide means to change an alias into a new type like type x = type integer; (or is that Borland ext?) Moreover C and C++ typesystems are different (and often confused), and so are K&R and Ansi C. (K&R pretty much has none).

However Pascal is indeed not 100% strong typed, even though a lot of people think so. E.g. Pascal has a lot of type equivalency between the numeral types, which is not strictly typed. (see e.g. M2), just like C. It also doesn't have a notational difference between a cast and a conversion, just like C ( (int) <something of float containing 1.0> returns 1, not the first bytes of the float value cast)

So some nuancing might be in order. (but considered dull probably)

-- Marco van de Voort

---

Not to start a holy war or anything, but here's the passage that got my dander up:

Pascal allows passing parameters either by value or by reference. In C, parameters can be passed only by value, which is a serious flaw.

I would call the "serious flaw" designation subjective at best and ignorant at worst. C does too have call-by-reference! I prefer the C notation, in which the function call's syntax indicates that the argument is being passed by reference. I think it's perilous to be able to redefine a function/procedure argument's var-vs.-val later without requiring a reexamination of the callers. I also once wrote a semi-epic Genie Pascal program in which I was passing a value by reference down a fairly tall call tree. I dropped the var in the declaration of one of the higher functions, and it resulted in some perplexing, though non-fatal, behavior. I would've had a lot more trouble making the same mistake in C.

-- Ventura 23:12, 2004 Oct 14 (UTC)

C has no call by reference. It can pass a pointer by value though. That's different.

[Scott A. Moore] The use of &var notation in C to make variable references the same as value references may be a neat trick, but it has a price. The notation is indistingusable from the notation form a passed array. func(int *a) could be a as variable parameter, or it could be a as an array of ints. This created, for example, huge problems when making an automated header translator for C to Pascal, which is pretty much required to do any real interface work today, since all operating systems and packages are specified in terms of a C header.

This is yet another case where Pascals more specific notation pays off.

Turbo Pascal

The article says in part that Borland Turbo Pascal was only available on one platform. I believe this is incomplete. Up to Turbo Pascal version 3.0, you could also purchase it for Z80-based CP/M systems. The compiler was quite fast and pleasant to use, with a very good integrated editor. At the time you could take the same source code and compile it on either CP/M or an IBM PC running under MS DOS with almost no changes to the source file - if you used only the built-in Pascal functions for screen addressing, programs could be competely portable. The two versions used the same manual, with appendices explaining the PC and CP/M specific peculiarities. The PC version *could* manipulate slightly larger amounts of data in memory since it dedicated an 8086 segment to the variables (64K), whereas by necessity the Z80 version had to share all 64 K of RAM with the program code, data, and CP/M itself (and even the edit environment, though I believe it swapped out during program execution). An even earlier hobby-grade CP/M compiler for Pascal was JRT Pascal - which actually encouraged you to give away the program, though they retained copyright on the manuals. Sadly JRT Pascal was incredibly buggy and the company also managed to over-promise and under-deliver. --Wtshymanski 02:16, 15 Dec 2004 (UTC)

True, besides the Z80, there also was a m68k Mac version. I can vaguely remember TP1/8086 having a unified 64k model, are you sure you aren't comparing later versions?

User: Marco van de Voort

[Scott A. Moore] I have version 1.0 with the Manual, and it supported 8086/PC and Z80/CP/M. This was the age when there were still more CP/M systems than PC systems. By the way, TPC 1.0 also claimed to be standards compliant, even though they clearly were not. They later dropped the claim.

Edits

I have added this section because, being there exist widely differing interpretations of PascaL facts and history, I have stated my reasons for my edits to this page. It is not my intent to make this is political issue, but the page, as was written, read like a review written by a C programmer. I have not struck the entire "C to Pascal" comparison, even though it should actually be struck. Pascal is a language on its own, not a counterpoint to C. All in all, I would like to see this page more factual and more neutral, and hope all parties will agree to that.

samiam@moorecad.com:

1. Struck the reference to "C is a language for professionals". This implies that Pascal is not, and in any case was irrelevant to the subject at hand.

2. Struck the statement that "Pascal does not have differing lengths of integers and unsigned types". This is entirely untrue. Pascal just has a different notation for same, examples:

type n = 0..256

is unsigned byte. If a particular compiler chooses to interpret this as always a 32 bit integer, then that is a limitation of that compiler. A good compiler is free to limit the storage and signed status of the type.

3. I struck the entire diatribe at the end of the "C vs. Pascal" section containing judgment calls about Pascal being "flawed", about later improvements to Pascal making the language "as useful as C", etc. Certainly a section about later improvements to Pascal is in order, but its hardly a "C vs. Pascal" issue, nor C vs. Pascal warfare relevant to the information about Pascal. Just the facts please.

4. I have moved the C vs. Pascal section down. The purpose is to define "what is Pascal" first. Comparisons with other languages is certainly relevant, but not before the user is even informed about the subject itself.

5. In the "hello, world" example, I struck the note that "input, output are not required [in the header]. The text did not state "on some compilers" or other clause. Original Pascal certainly does require that "output" appear in the header.

6. From the "criticism" section, I struck the paragraph about "taking Pascal seriously". With my edits above, this whole article is more neutral, so a plea such as this is no longer necessary.

7. Added a reference to mine own page for standard Pascal.

(Scott A. Moore: I authored the above. Apologies for placing it on the wrong page, and thank you for correcting that. I understand Wikipedia much better now :-))

(This text was added to the article page by 192.18.42.10/192.18.42.11) — Stevie is the man! ^{Talk | Contrib} 04:00, 13 Mar 2005 (UTC)

Pascal vs C

[Scott A. Moore] I propose we strike or change this section. The Wikipedia entry on C does not compare itself to Pascal, nor do we include comparisions to other languages. It became traditional somewhere down the line for C users and Pascal users to fight over their langauges, probally because these were two competing languages during the Microcomputer revolution.

As I said above, Pascal is not a counterpoint to C, it is a language. The section on C would be better as "differences with other languages" or somesuch, and hardly needs to go point by point by point of the exact differences with C.

I propose that history has a bigger view than to be about perpetuation of a petty user fight. Comments ?

2005/05/25 I have left the above comment up for some time. I will execute the proposed change.

[Marco van de Voort] Scott: kill it off. I also would, in general, like to see more history move to a/the "historic" section, and see the general text of the article more about the present... or at least the last decade.

OTOH the stigma that stick to pascal still haunt us today. So partially the C vs Pascal discussion is still alive.

So I left the comment about striking the Pascal vs. C up for some time, and it was restored without even a comment as to why. So clearly whoever restored that does not want to talk rationally about the matter.

I'm not going to use this page to fight over Pascal, so I am not going to get into a delete war. Whoever WANTS that C passage clearly is a Pascal detractor, which is the WRONG kind of person to edit the Pascal page (somewhat like putting Bolton as diplomat to the UN). The C page does not talk about Pascal, or discuss why Pascal is better. PASCAL IS NOT A COUNTERPOINT TO C. Its a language. --Samiam95124 20:24, 2 Jun 2005 (UTC)

I have no objection to comparisons between Pascal and C. If someone (Samiam95124?) doesn't like the way they're written, they should be edited for NPOV. Having a rebuttal isn't the way encyclopedia entries should work. The informal self-reference ("As a Pascal promoter and compiler maker, I will state the Pascal point of view.") belongs on a talk page, not in an article. Let's edit what's there and make it NPOV instead of writing a rebuttal section. Gary D Robson 21:11, 2 Jun 2005 (UTC)

I don't know what NPOV is, but sure, lets settle on a format. I have two primary objections to the section on Pascal and C, which I would appreciate if you could address.

First, as said, the entry on the C language does not compare itself to Pascal. Why not Pascal vs. Snobol ? Lisp ? The entire idea of listing Pascal vs. Language X seems to me to invite languages wars here. If the idea was to point out what is not good about Pascal, the C language page has a section on "problems with C", and that certainly looks appropriate.

Second, that section (Pascal and C) certainly appears written by a C promoter/ ethusiast. The several mentions to "lack" on Pascals part indicate a bias to me. Lots of languages don't have (or need) preprocessing, pointers with wild abandon, etc. Yet I don't think that these languages are considered "lacking".

It seems to me that Wikipedia articles in general, and language articles in specific, should be left to people that like and study the subject. Otherwise, it becomes an invitation to Wiki Wars. Why should I not then go to the C language page and post about how bad that language is ?

So having got that off my chest, I will list my preferences in order.

A. Delete the "Pascal and C" section, or change it to "Problems with Pascal". I am not trying to suppress opinions about what is not right with Pascal, just cast it in other terms than "Pascal is flawed because it is not C".

B. Tone it down. Pascal is a problem because it does not have a preprocessor ? Come on. Most languages don't have preprocessors. Pascal has constant declarations and type declarations, both of which the C preprocessor was designed to supply. That leaves Macros, which have virtually everybody I know, including Stroustrup, disgusted with the lousy code that gets written under C.

Thanks for the attention.--Samiam95124 21:30, 2 Jun 2005 (UTC)

I'll take a guess you mean Neutral Point Of View. Here here, that exactly expresses my thinking. The more neutral, the better (and thats what I have strived for in past edits here).--Samiam95124 21:32, 2 Jun 2005 (UTC)

Yes, that's what I meant. I think the section helps. Let's face it, more programmers know C than Pascal, and this gives people something to compare the language to. I've taken a first cut at making the section more of an informative comparison and less of a language-bashing excercise. Maybe we could add some syntactical differences to the list and make it really useful? You'd probably be better for that than I. I haven't used Pascal in five years, although I coded extensively in UCSD Pascal and Delphi. Someone more current in both languages should work on the comparison list. Gary D Robson 21:38, 2 Jun 2005 (UTC)

All right, I'll take your first point, and I'll go through the new version of the section here.

• "C has bitwise operations....." There is a misconception that Pascal sets are about bit manipulation. Actually, sets are horrible for bit manipulation, for a lot of reasons. First, when doing bit assembly/disassembly, you generally want to shift bit fields around, with shift left and right. Sets aren't designed to do that, they don't have any concept that you might want to take sequential bits together, or move them to other parts of the word, etc. Pascal users manipulate bits the same way that C users do, which is why bit shift operators are a common extention to pascal. I didn't include them in my compiler, because the compiler already does a shift when you do a * or DIV. "and" and "or" is another matter (you can do it in standard Pascal, but its hard and not efficient). Finally, the major reason you would want to shift bits is to pack multiple bits or other short operands into an integer, which Pascal does for you automatically via the "packed" keyword on a compiler that knows how to do that. So for example:

a = packed record

  bit1: boolean;
  bit2: boolean;

  ..

end;

On a compiler that knows how to pack would allow bit fiddling without the need for shifts or "and"s.

• "C allows much greater freedom with pointers" starts ok, but wanders off. C has "malloc" and "calloc", Pascal has "new", and new is built into the language, not a library add on, so by some measures Pascals pointer methods are actually more flexible, because "new" knows what is being allocated (and hence can handle tag field allocations on variant records, for example). I think I disagree with "C is more concise for low level programming", since, as I handle a lot of low level programming in ISO 7185 Pascal myself, and its simply a matter of declaring a fixed object in memory via an external file vs. placing a magic number in the file, which is bad practice even in C. In general, I guess this paragraph is factual, but it makes it sound as if Pascal is braindamaged instead of simply having a different method of doing that same job.

• "Pascal lacks preprocessing" Again this appears entirely irrelivant. There is no need for one, so there is no "lack". In any case, it isn't even true. There are lots of preprocessors available for Pascal. Its a separate program, just as it used to be for C (it got integrated with the C compiler because preprocessors are notorious for giving bad error messages).

• "Pascal lacks continue and break operators" Pascal also lacks brackets instead of begin..end, /* */ comments, etc. "lack" is the wrong word. Wirth specifically disincluded those statements, for good reason.

• "Pascal permits nested functions" actually so does C, its in the C99 definition :-) Seriously, this brings up the point, are we comparing old Pascal, old C, or some other mix ?--Samiam95124 00:27, 3 Jun 2005 (UTC)

Ok, so I'll be helpfull. I program about %50/%50 C and Pascal these days, so here is my version of your comparision:

• C features short syntax elements with special characters, for example "{" instead of "begin", "&" instead of "var", etc.
• C is oriented towards compact or very compact syntax. Functions are declared without a keyword in C, but in Pascal, "function" is required.
• C has many special operators, for example "a *= b" instead of Pascal's "a := a*b". C has bit shifts (<<, >>) bitwise and and or, plus many other special operators such as ?:.
• C allows assignment anywhere in an expression, including multiple assignment within an expression. In Pascal, assignment is a statement.
• C allows the creation of a pointer to any program object, global variables, locals, etc. In C, pointers and arrays are considered equivalent.
• In C, boolean types are the same as integers.
• C allows "early out" break and continue operators.

Notice that the above is NPOV (your term). I didn't "ding" C for having wild pointers. C lets you do more with pointers. Thats C. Pascal isn't C.

Left out, on purpose were:

"C bitwise vs. sets". Sorry, its just misleading. "C has more operators" makes more sense.

"Pascal allows passing ... by value or by reference" C does too, it just uses a different method.

"Pascal provides subrange types" Ok I guess, but dosen't (to me) make sense all on its own. Pascal has a lot of typing restrictions, thats only one of them. Others would be, typed indexes, discriminated variants instead of unions, etc. Do we list them all ?

"Pascal lacks preprocessing". I think I beat that into the ground.

"C lacks typesafe enumerated types" Well, it actually has those and has since ANSI C. It still isn't typesafe, but none of C is.

"Pascal permits nested functions" So does C, since C99.

You know, I actually use C a lot and like it in many situations. Its this idea that all languages we like have to be amagamated into one giant superlanguage that is suspect. Pascal shouldn't look like C, and C shouldn't look like Pascal.

Cheers!--Samiam95124 00:27, 3 Jun 2005 (UTC)

I would like to make one last pitch for the elimination of the Pascal vs C section. Looking around in Wikipedia, NO OTHER language has this comparision to C. Look at Basic, ADA, algol, lisp, Fortran, even Java (which came from C!). None have this apparent need to be compared to C. I invite you to look at these, and any other language entries in Wikipedia, and explain why Pascal needs to have it.

Further, it is traditional for C and Pascal users to fight. The reason why is that the languages arrived at roughly the same time, and vied for the status of most popular general purpose language of the Microcomputer age. Also, most programmers learned both at one time or another. I would argue that there is no such thing as a really neutral comparision of these languages.

The right answer for this article to be NPOV is to have it not make this unfortunate comparision. Then it is truly neutral. Otherwise, whatever form you have this comparision in, it invites conflict.

--Samiam95124 04:18, 3 Jun 2005 (UTC)

Okay, I think you've made your point. How about if we remove the Pascal vs. C section from here, and encourage anyone who wants to put in the effort to create a new article comparing the languages? Then both the Pascal article and the C article can link there. Gary D Robson 13:19, 3 Jun 2005 (UTC)

I'll write the first draft of the new article, probally over the weekend. Of course, its going to look something like what I outlined above, but then others will be free to edit it.

Wow, do you know how may pages we can create comparing languages ? Isn't it the square of their number or something like that ? :-)--Samiam95124 18:40, 3 Jun 2005 (UTC)

I have added a page called Pascal and C (the same title as the section under Pascal). For a first pass, I think it came out fairly well. However, I invite spelling corrections and edits. When (if ?) you are satisfied with its contents, we can make the change to strike the section from this article, and link that article.

You are on your own for C vs. Snobol comparisions! :-)--192.18.43.10 02:04, 4 Jun 2005 (UTC)

Saw a couple references to cleanup of the Pascal and C page, but no changes noted, so I have gone ahead with modifing this page to point to that, and remove the Pascal and C article from this page. I will personally pass on modifying the C page to also point to that. I don't really see myself arguing with the C zealots for why they need such a link on their page.--Samiam95124 22:02, 13 Jun 2005 (UTC)