Difference between revisions of "Talk:Why use Pascal"

From Lazarus wiki
Jump to navigationJump to search
 
(2 intermediate revisions by one other user not shown)
Line 7: Line 7:
 
This is also not really true, depending on the definition of a sub-language. STL/MFC are libraries not languages, and one needs to learn RTL/FCL/LCL/whatever you want to work with anyway. Might be easier but has not really got anything to do with the language Pascal itself.
 
This is also not really true, depending on the definition of a sub-language. STL/MFC are libraries not languages, and one needs to learn RTL/FCL/LCL/whatever you want to work with anyway. Might be easier but has not really got anything to do with the language Pascal itself.
  
Good points of pascal are the strong typing and the readability focus, plus fpc's goal to keep language feature additions to a minimum, ie. they really have to add something substantial and not save only some typing. These things are missing on the page.
+
Good points of pascal are the strong typing and the readability focus, plus fpc's goal to keep language feature additions to a minimum, ie. they really have to add something substantial and not save only some typing. These things are missing on the page.  
 +
 
 +
Strong typing avoids a bunch of errors in Pascal-programs in production. This in contrary to C-programs: they present many unexpected and scarcely occuring errors once in production. Due to incompatible type assignments and parameter passings.
 +
 
 +
Also the syntax of Pascal is much more strict. E.g. ' := ' differs from ' = ', where C accepts both in ambiguous contexts. With fatal errors in production. The same applies to the Switch/Case construct. The use of brackets  (). And the possibility of defining user types, that implies strict type checking at compile time. This avoids errors in production time, becaude this type of errors, in contrast to C, must be solved to compile the source.
 +
 
 +
I would add "Real programmers don't use Pascal". https://www.pbm.com/~lindahl/real.programmers.html It is the ultimate scientific and ironically prove of the superiority of Pascal above all other languages.
 +
 
 +
== [[Special: Diff/154068/154590|November 2022 changes]] ==
 +
 
 +
@[[User: Zanden30|Zanden30]]:
 +
* Why did you [[Special: Diff/154068/154577|condense “Pascal has OOP”]] to one “miscellaneous” sentence? In my opinion [[Special: Diff/81503|it deserves its own section]], because there was the misconception “Pascal is ''soooo'' old, it does not even support <OOP|generics|…>”.
 +
* The point of the [[Special: Diff/81503|readability section ''spelling out'' all symbols]] was to demonstrate readability. Why did [[Special: Diff/154578|you convert everything back into symbols]]? By the way, your change mistranslated “inch sign” into an <syntaxhighlight lang="c" inline>'</syntaxhighlight> which disables the proper interpretation of <syntaxhighlight lang="c" inline>\n</syntaxhighlight>.
 +
* What is “[[Special: Diff/154577|syntax safety]]”? I couldn’t find a Wikipedia entry for that.
 +
* You replaced the [[Special: PermaLink/154068#Real assignment operator|real assignment operator section]] with a [[Special: Diff/154068/154577|new section]]. It is indeed two points ''mixed'' now. The strict separation of statements and expressions and the provision of a “real” assignment operator. I am really missing the ''mathematical argument'' now. Do we (by the looks of it) have a system of equations, or is it definitions?
 +
* Also I did not want to refer too often to C’s shortcomings. You know, it shouldn’t sound to a reader like a C bashing. There ''are'' scenarios C is an adequate language to program in. Maybe we could tone down that a bit? The [[Special: Diff/154582|new “Native String support” and “Parameter passing” sections]] do not really need to mention C by name, do they?
 +
‑‑[[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|talk]]) 19:31, 27 November 2022 (CET)

Latest revision as of 20:31, 27 November 2022

"Most of the developing time spent in Pascal is on the program itself. Unlike C and C++ like language, the developer does not need to focus on managing the memory of variables, the structure of very simple things like passing parameters and returning them back again."

You don't need to manage memory of the string and dynamic array types, but of all others, GetMem, classtypes.Create you do; this paragraph is misleading, incomplete, and/or inaccurate ;-).

"That is why Pascal developers do not need to learn a new sub-language inside the same language, like C++ STL, MFC and other sub languages inside C and C++."

This is also not really true, depending on the definition of a sub-language. STL/MFC are libraries not languages, and one needs to learn RTL/FCL/LCL/whatever you want to work with anyway. Might be easier but has not really got anything to do with the language Pascal itself.

Good points of pascal are the strong typing and the readability focus, plus fpc's goal to keep language feature additions to a minimum, ie. they really have to add something substantial and not save only some typing. These things are missing on the page.

Strong typing avoids a bunch of errors in Pascal-programs in production. This in contrary to C-programs: they present many unexpected and scarcely occuring errors once in production. Due to incompatible type assignments and parameter passings.

Also the syntax of Pascal is much more strict. E.g. ' := ' differs from ' = ', where C accepts both in ambiguous contexts. With fatal errors in production. The same applies to the Switch/Case construct. The use of brackets (). And the possibility of defining user types, that implies strict type checking at compile time. This avoids errors in production time, becaude this type of errors, in contrast to C, must be solved to compile the source.

I would add "Real programmers don't use Pascal". https://www.pbm.com/~lindahl/real.programmers.html It is the ultimate scientific and ironically prove of the superiority of Pascal above all other languages.

November 2022 changes

@Zanden30:

‑‑Kai Burghardt (talk) 19:31, 27 November 2022 (CET)