שיחה:PL/I

מישהו יכול לכתוב דוגמת קוד? טרול רפאים 12:18, 11 יולי 2005 (UTC)

כן. דוד שי 17:42, 11 יולי 2005 (UTC)

תחביר תלוי-הקשר

שמעתי שהייחוד של השפה הוא בכך שהתחביר שלה מבוסס על דקדוק תלוי-הקשר,ומאפשרת קוד נוסח:

IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;

הייחוד הוא בכך שהיא הייתה אחת הבודדות שהיו כאלה, והייתה יחסית פופולרית. המתעתק • שיחה 04:03, 10 ביוני 2007 (IDT)

הפקודה שכתבת היא אכן פקודה חוקית ב-PL/I. אביהו • שיחה 06:53, 10 ביוני 2007 (IDT)

אז כדאי לשלב את זה בערך. זה מאפיין שאסור לוותר עליו, ומהווה חלק משמעותי מזכות הקיום של הערך. המתעתק • שיחה 07:06, 10 ביוני 2007 (IDT)

אין שום דבר תלוי הקשר במה שנכתב כאן. זה בסך הכל החלטה להגדיר מילות-מפתח ולא מילים שמורות. הביטוי שמופיע כאן ניתן להגדרה באמצעות דקדוק חופשי הקשר בצורה פשוטה. --אלעזר - שיחה 23:08, 13 במאי 2012 (IDT)

אתה בטוח? נדמה לי שהשימוש בסימן "=" הן להשוואה והן להשמה נחשב "תלוי הקשר", לא? (גילוי נאות - אין לי השכלה ב-CS). קיפודנחש - שיחה 23:04, 14 במאי 2012 (IDT)

הסמנטיקה שלו תלויית הקשר, אבל את הביטוי הזה אפשר להגדיר באמצעות מבנה תנאי שיוצרים דקדוקים חסרי הקשר בכל שפה, ופשוט לא לאסור על מזהה כמו IF. המשמעות הכפולה של האופרטור "=" היא גם כן תלויית הקשר, אבל זה דבר שקיים בשפות רבות, שהן גם כן עם דקדוק חסר הקשר, כמו ML. אין שום דבר "ייחודי" בשפה תלוית הקשר - זה פשוט קשה לקימפול. ובמובן מסויים רוב השפות הן תלויות הקשר (אי אפשר להגדיר בדקדוק חסר הקשר חובה להצהיר על משתנה לפני שמשתמשים בו, או התאמה בין מספר הפרמטרים למספר הארגומנטים בקריאה לפונקציה. בקיצור, אני לא יודע אם PL/I היא תלויית הקשר ברמה שונה משפות אחרות (כמו C או ++C), אבל צריך מקור או הוכחה לזה, ואם כן צריך לציין את זה כמאפיין שלילי (נוסף) של השפה, ללא ספק.

וראה התייחסות בויקי האנגלית:

Some argued that PL/I was unusually hard to parse. The PL/I keywords were not reserved so programmers could use them as variable or procedure names in programs. Because the original PL/I F compiler attempted auto-correction when it encountered a keyword used in an incorrect context, it often assumed it was a variable name. This led to "cascading diagnostics", a problem solved by later compilers.

שום דבר לגבי תלות-הקשר. סתם כאב ראש. --אלעזר - שיחה 01:29, 15 במאי 2012 (IDT)

נדמה לי שאתה נלהב מדי למצוא מאפיינים שליליים ב-PL/I. כל מי שכתב קובול סבל מבעיית המילים השמורות בשפה זו, שפגעה ביכולת לתת שמות למשתנים וחייבה אלתורים. ב- PL/I בעיה זו נפתרה - אין מילים שמורות. זהו יתרון של השפה בהשוואה לקובול. כן, קשה יותר לכתוב את הקומפיילר, אבל איזה משקל יש לקושי זה בהשוואה לקלות התכנות.

באשר לבעיה שהייתה בגרסאות ראשונות של הקומפיילר: זה מצב טבעי בשפה פורצת דרך כמו PL/I. אין לי ספק שגם בשפות פורצות דרך אחרות היו חבלי ילדות. דוד שי - שיחה 07:24, 15 במאי 2012 (IDT)

בכל שפה מודרנית רצינית יש מילים שמורות. קל יותר לכתוב בלעדיהן, והרבה יותר קשה לקרוא. בכל מקרה, לענייננו, השאיפה היא לעשות את שפת התכנות חסרת הקשר ככל הניתן (מקובל לתאר דקדוק של שפות בעזרת צורת EBNF שהיא מקבלה למבנה של דקדוק חסר הקשר) ונטולת דו-משמעויות (אם כי להוכיח באופן כללי שדקדוק כלשהו הוא חד-משמעי זאת בעיה לא כריעה). שפת ++C ידועה לשמצה בכך שאצלה זה לא ממש ככה, ובמיוחד הדקדוק של השפה הוא למעשה שלם-טיורינג ולכן בלתי-כריע. לכן, אם PL/I תלוית הקשר (שוב - אני לא יודע אם זה המצב), אזי זאת בעיה. זה הופך את הדקדוק שלה לקשה יותר ללמידה, להידור ולקריאה. אם אתה רוצה להביא את זה כתכונה חיובית, תצטרך להביא מקור של מומחה שטוען את זה, ואני משוכנע שלא תמצא לזה שום מקור רציני. יש סיבות תיאורטיות כבדות משקל לקושי האינהרנטי להדר שפה תלוית הקשר, ולכן גם לקושי האינהרנטי להבין אותה.

גם בנוגע למילים שמורות - לא נתקלתי מעולם במקור שטוען שלאפשר לקרוא למשתנה שלך בשם IF זאת תכונה חיובית. אין שום ספק ביכולת של תכונה כזאת לבלבל את מי שמתחזק את הקוד - אחלה Code Obfuscation, כפי שמראה הדוגמה שנתנו פה למעלה. אלא מה, יש בשפה יותר מדי מילות מפתח? הנה עוד בעיה. לא רק שהן לא שמורות, אלא סביר שהמתכנת הממוצע לא מכיר את כולן, וישתמש בהן בטעות - אולי זה אפילו יתקמפל עם תוצאות שונות לחלוטין מאלה שהוא התכוון אליהן.

כל הבעיה בלתת שמות למשתנים היא ההגבלות השרירותיות על האורך שלהם שהיו בשפות הראשונות. ברגע שהאורך לא מוגבל, אין שום בעיה. דוד, אמרת שאתה מתכנת ב-PL/I. אי פעם קראת למשתנה שלך IF? זה הציל אותך במקרה שבו נגמרו לך השמות ההגיוניים? כי אני לא נתקלתי בצורך הזה בשנים (הקצרות) שאני מתכנת ב-C, ג'אווה, ++C, פייתון ועוד שפות איזוטריות. במיוחד אין צורך כזה בשפה מבנית עם משתנים לוקליים, ו-PL/I אכן היתה שפה כזאת.

ביקורות מהסוג שהזכרתי אפשר למתוח על רוב שפות התכנות, וגם עושים את זה. אבל "חבלי ילדות" בשפה שמעולם לא זכתה לבגרות - גיל התבגרות, לכל היותר - מעידים על כמה "חבלי הילדות" שלה הם קשים. צריך לתת לשפה את הכבוד שמגיע לה כשפה פורצת דרך, ולמתוח עליה את הביקורת המגיעה לה בתור שפה פורצת דרך לא-מוצלחת. בכל מקרה, את הוויכוח הזה אפשר להמשיך בפסקה השניה כאן. בנוגע לדקדוק תלוי הקשר - אם זה כך, זאת תכונה שלילית ללא ספק. וצריך למצוא מקור (או טוב מזה, הוכחה) לטענה שזה כך. --אלעזר - שיחה 20:26, 15 במאי 2012 (IDT)

אינני מסכים אתך, אבל הגיע הזמן לתת לערך לדבר בעד עצמו. דוד שי - שיחה 21:01, 15 במאי 2012 (IDT)

(אני שובר כי חרגנו קצת) מסתבר שהשפה היא חסרת-הקשר לפחות כמו כל שפת תכנות מקובלת. מצאתי את המסמך הזה שבו היא מתוארת בעזרת EBNF (עצום - 151 כללים, ודף שלם של מילים וסימנים), למעט חלק קטן מהשפה. כך שאין מקום לתאר אותה כשפה תלוית-הקשר בערך. --אלעזר - שיחה 21:46, 15 במאי 2012 (IDT)

הערך מוטה

בזמן כתיבת שורות אלה, הערך מהלל ומפאר את שפת התכנות PL/I, שכיום ברור שהיא שפה מתה, שהיתה כישלון טוטאלי (כמו שאמר המרצה שלי בטכניון, וכל מקור אובייקטיבי על השפה שנתקלתי בו) שלימד את מעצבי השפות שלאחריה בעיקר ממה להימנע (העמסת פיצ'רים באופן לא אורתוגנלי). כל זה למרות ש-IBM עמדה מאחוריה ומנעה התפתחות של Algol-68, שנחשבת עד היום לשפה מוצלחת למדי (הבעיות שלה לא קשורות לתכנון טהור אלא לשיווק ולמימוש). --אלעזר - שיחה 23:07, 13 במאי 2012 (IDT)

אין צל של ספק שבהשוואה לקודמותיה, קובול ופורטרן, PL/I היא שפה מתקדמת, שהעקרונות שמומשו בה ניכרים גם בשפות תכנות מודרניות יותר. אלגול לא יצאה מתחומי האוניברסיטאות, ולכן אין לה חשיבות מסחרית. PL/I לא הצליחה להחליף את קובול ופורטרן הגרועות ממנה, אך בוודאי לא הייתה כישלון טוטאלי - היא הייתה בשימוש נרחב בצה"ל, עד אמצע שנות ה-80 נלמדה בכל האוניברסיטאות בישראל (כולל הטכניון) שבהן פעל מחשב IBM, זכתה לתפוצה נרחבת בברית המועצות, ו(גילוי נאות) אני משתמש בה עד היום (לפיכך אם היא מתה, יש חשש שגם בי אין הרבה חיים). דוד שי - שיחה 07:53, 14 במאי 2012 (IDT)

אני אצטט מתוך הספר Concepts of Programming Languages עליו אני מסתמך בערך:

Any evaluation of PL/I mustbegin by recognizing the ambitiousness of the design effort. In retrospect, it appears naive to think that so many constructs could have been combined successfully. However, that judgement must be tempered by acknowledging that there was little language design experience at that time. Overall, the design of PL/I was based on the premise that any construct that was useful and could be implemented should be included, with insufficient concern about how a programmer could understand and make effective use of such an array of constructs and features. Edsger Dijkstra (...) made one of the strongest criticisms of the complexity of PL/I: "I absolutely fail to see how we can keep our growing programs firmly within the intellectual grip when by its sheer baroqueness the programming language - our basic tool, mind you! - already escapes our intellectual control." In addition to the problems with the comlexity due to its large size, PL/I suffered from a number of what are now considered to be poorly designed constructs. Among these were pointers, exception handling, and concurrency, although we must point out that in each of these cases the construct had not appeared in any previous language.

התקן האחרון שגיליתי עליו של השפה היה בשנת 81. היא הצליחה יותר מאלגול פשוט כי היא נתמכה על ידי IBM, בנוסף על שיווק לקוי של אלגול. לעומת זאת, אלגול השפיעה על כל שפה אימפרטיבית שהגיעה אחריה. אני לא אומר שצריך להלל את אלגול בערך שלה, רק שהקורא הממוצע שייכנס לערך יבין היטב למה (על אף הקידום המסיבי שלה על ידי IBM), שפת PL/I מעולם לא היתה יותר מ"הצלחה חלקית", כפי שמציינת המשך הפסקה שציטטתי, ו"שפה כמעט מתה", שוב ציטוט. קובול ופורטרן לא גרועות ממנה מעבר לכך שהן פותחו לפניה, והן ייעודיות ומתאימות, כל אחת לתחומה, לא פחות מכל שפה מודרנית היום (פורטרן לא נופלת מאף שפה בכל הנוגע לאופטימיזציה של תוכניות העוסקות בעיקר בחישובי נקודה צפה, ואין אף שפה מודרנית שהיא משמעותית מתאימה יותר מקובול ליישומים מסחריים. שני אלה על פי אותו ספר ועל פי מה שמצאתי ממקורות אחרים). בקיצור, מבין השפות הגדולות שיצא לי להיתקל בהן או ללמוד עליהן, PL/I מדשדשת עמוק בתחתית, מבחינת ההערכה המקובלת שלה, וגם תפוצה (כיום). --אלעזר - שיחה 21:55, 14 במאי 2012 (IDT)

מויקיפדיה האנגלית: "השפיעה על" - SP/k, B, REXX, AS/400 Control Language. --אלעזר - שיחה 21:58, 14 במאי 2012 (IDT)

ללא צל של ספק, קובול ופורטרן של שנות ה-60, ה-70 וה-80 הן שפות מפגרות בהשוואה ל-PL/I, לפי כל קריטריון סביר להערכת שפות תכנות. קובול הייתה "שפת ספגטי" איומה, ופורטרן הייתה סבירה לאלגוריתמים (פחות טובה מ-PL/I) אך בלתי נסבלת במה שנוגע לעיבוד נתונים. אלגול, כאמור, לא התחרתה באף אחת מהן, משום שלא יצאה מגבולות האקדמיה. ייתכן שקובול ופורטרן התפתחו מאז נפרדתי מהן לפני שנים רבות, אך את הספר שקובע "אין אף שפה מודרנית שהיא משמעותית מתאימה יותר מקובול ליישומים מסחריים" אני מציע שלא תקרא יותר, מפני שמקומו בפח האשפה. קובול זכתה להצלחה רבה ביישומים מסחריים, אך היא שפה גרועה ביותר. דוד שי - שיחה 22:05, 14 במאי 2012 (IDT)

אלגול יצאה מגבולות האקדמיה וזכתה לתפוצה מסויימת באירופה, אם כי לא בליגה של PL/I, שבפני עצמה לא בליגה של פורטרן\קובול. ובכלל מידת הקבלה של שפה (מלכתחילה) היא לא המדד היחיד, אבל אם שפה מגיעה לתפוצה ואז נעלמת, לעומת זאת, זה אומר עליה כל מיני דברים (למשל פסקל, שהיא שפה לא רעה אבל לא מתאימה לתכנות בקנה מידה גדול).

שים לב שאתה מדבר על פורטרן מחוץ לתחום שאליו היא תוכננה. PL/I היתה אמורה להחליף את שתיהן. זה לא עבד, ולא מסיבות של שיווק כי היה לה גב חזק מאוד. הספר דיבר על מבני הנתונים של קובול, יותר מאשר על מבני הבקרה שלה למשל - אני מבין ש-COBOL היא שפה גרועה, אבל אם PL/I טובה ממנה זה לא התבטא בתעשיה (לפי הערכות שראיתי בכמה מקומות, COBOL היא השפה שבה כותבים הכי הרבה מתכנתים מקצועיים, נכון לשנת 2000-2002 בערך. אני מניח שזה השתנה מאז, אבל זה נתון משמעותי).

בשורה התחתונה, אתה אומר שיש ל-PL/I הרבה יתרונות על שפות שתוכננו 15 שנים לפניה. אין ספק בזה - המון פיצ'רים חדשים - וזה גם צריך להופיע בערך. הנקודה היא שלמרות המאמץ התכנוני הלא מבוטל, והניסיון שנלמד משתי קודמותיה (ואולי גם LISP?) ולמרות התמיכה של החברה הגדולה ביותר בעסק הזה, השפה מעולם לא הגיעה לסדרי גודל שאליהם תכננו אותה, וגם נעלמה הרבה לפני השפות המפגרות אותן התיימרה להחליף. ואז הערך הזה מנסה להסביר איזו שפה מרשימה היא. היא לא.

בקשר לספר - זה ספר לא רע בכלל, ויש לי למה להשוות כי זה הספר השלישי שאני קורא בנושא הספציפי הזה (עקרונות של שפות תכנות). --אלעזר - שיחה 22:54, 14 במאי 2012 (IDT)

אין ויכוח על כך שבמערב קובול הצליחה הרבה יותר מאשר PL/I. אין לי הסבר טוב לכך. אני בספק האם PL/I ניסתה להתחרות בפורטרן, אבל ברור לי היתרון של פורטרן - היא פשוטה יותר, ועונה על הצרכים הפשוטים (מבחינת ארכיטקטורה של שפת תכנות) של משתמשיה, אנשי המדעים המדויקים. אין סיבה שהם יעברו לשפת PL/I המסובכת יותר. בכל אופן, דיברנו די, והגיע הזמן להרחיב את הערך. דוד שי - שיחה 23:03, 14 במאי 2012 (IDT)

הסבר לעריכות

ראשית, Elaz85, תודה רבה על הרחבת הערך. כעת הסבר לעריכתי:

• הסרתי השוואות לשפת C. שפה זו איננה תקן שכל מתכנת מכיר, ולכן אין תועלת בהשוואה אליה. יתרה מכך, כיוון ש-PL/I פותחה שנים אחדות לפני C, הרי שאם קיים דמיון הוא של C ל-PL/I (בהקשר זה, יחס הדמיון אינו סימטרי). דברים אלה נכונים, ביתר תוקף, להשוואה ל++C.
• מרווח בין מילים: פורטרן מיוחדת בכך שאין בה חשיבות למרווחים - ניתן לשתול מרווחים בין האותיות של מילת מפתח, וניתן לכתוב ללא מרווחים כלל, המהדר לא יתרגש מזה. מבחינה זו, PL/I היא שפה נורמלית, שיש בה חשיבות למרווחים, ולכן אינני רואה צורך בהשוואה לפורטרן - אין זה הבדל חשוב בין השפות.
• אין שפת תכנות שאי אפשר לכתוב בה קוד גרוע (כשם שאין שפה אנושית שאי אפשר לומר שטויות באמצעותה). לפיכך לעובדה שב-PL/I אין מילים שמורות (ולכן יש למתכנת הזדמנות לשטות אחת נוספת) אין חשיבות. המתכנת הסביר אינו משתמש לרעה בתכונה זו, ושימוש סביר בה אינו פוגע בקריאות. דוגמה: אף ש-INIT היא מילת מפתח ב-PL/I (למתן ערך התחלתי למשתנה) נוח מאוד לקרוא בשם זה לפרוצדורה שעוסקת במתן ערך התחלתי למשתנים. זה לא פוגע כהוא זה בקריאות, להפך - זה אפילו תורם לה. קל מאוד לזהות שבפקודה CALL INIT המילה INIT היא שם של פרוצדורה (ואינה משמשת כמילת מפתח). דוד שי - שיחה 20:08, 16 במאי 2012 (IDT)

• ההשוואה ל-C איננה בתור תקן, וברור מי לקח ממי. ספציפית עם ++C ההשוואה באה להראות שקיים צורך להקצאה מהסוג שהוזכר - הנה, גם ++C תומכת בזה (למרות שסוג ההקצאה הזה נשמע קצת מוזר). בדומה גם static בשפת C. לגבי משתנים לוקליים על המחסנית, צריך לכתוב שלמעשה כל שפת תכנות מודרנית רצינית פועלת כך (אצל ג'אווה ו#C מדובר ברפרנסים שמוקצים על המחסנית, ולא באובייקטים עצמם), אחרת זה נראה כמו תכונה מוזרה כשהיא איננה כך - היא סטנדרט. PL/I לא היתה הראשונה בעניין זה, אבל היתה הראשונה עם תפוצה רחבה.
• ההבדל לגבי המרווח בין מילים הוא חשוב, והוא לטובת PL/I. לא חובה להזכיר אותו בערך, אני מסכים.
• שפה לא יכולה למנוע ממתכנת לכתוב קוד גרוע. שפה יכולה לעודד מתכנת לכתוב קוד קריא, ולהקשות עליו לכתוב שטויות. פקודה מהסוג המצוטט בערך היא זוועתית, ואין שום סיבה בעולם ששפה תאפשר לכתוב דבר כזה. לא חובה להגדיר את כל המילים כמילים שמורות, וייתכן ש-INIT היא דוגמה טובה למילה כזאת - יש שפות מודרניות שמתנהגות ככה. אבל לאפשר קיום של משתנים בשם IF, THEN, ELSE, DO וכו' זה בוודאי מקשה על קריאת הקוד - כל קוד שמשתמש בתכונה הזאת, ללא יוצא מן הכלל. אני לא מכיר דוגמה לשפה רצינית אחרת המאפשרת התייחסות שונה ל-IF. בכל מקרה - זה מקל על כתיבת קוד, ומכביד על קריאתו. חד משמעית, ואם להביא מקור יעזור, אני אביא. אם לא, תוריד את כל ההתייחסות הביקורתית, לטובה או לרעה, מהערך - וישפוט הקורא. --אלעזר - שיחה 23:56, 16 במאי 2012 (IDT)

אגב, אם כבר מותר מילות מפתח, בוודאי שאסור לאפשר להם להיות מזהים של משתנים לא מוכרזים. זה נותן פתח לשגיאות מכאן ועד פתח תקווה - ואל תגיד לי "אזהרות". אני רואה איך מתכנתים מתייחסים לאזהרות. צריך להפחית אזהרות כמה שיותר. --אלעזר - שיחה 00:11, 17 במאי 2012 (IDT)

אם מאפיין מסוים של PL/I קיים בכל שפה מודרנית, ראוי לציין זאת, ולא להזכיר שפה ספציפית. אם מאפיין כלשהו חשוב, יש לנמק זאת מתוך עצמו, ולא בנימוק "גם ++C תומכת בזה".

ב-PL/I יש כלים מצוינים ליצירת קוד קריא, בוודאי בהשוואה לקודמותיה קובול ופורטרן, גם אם אינה כופה כללי כתיבה. מובן שהדוגמה המופיעה בערך לשימוש במילות מפתח היא אנקדוטה, ואינה משקפת כתיבה שגרתית. להחלטה של מפתחי PL/I ללכת בדרך זו יש כמובן מניע, והוא הרצון להימנע מבעיית המילים השמורות שהטרידה את מתכנתי קובול. לטעמך הם הרחיקו לכת בפתרון הבעיה.

ככל שאתה מרחיב את הערך, יתרונותיה של PL/I על קודמותיה (ולעתים גם על הבאות אחריה) הולכים ומתבהרים. המשך בדרך זו. דוד שי - שיחה 07:24, 17 במאי 2012 (IDT)

למרבה הצער, החסרונות לא מתבהרים, כי הם לא עוברים את המסננת שלך. ייתכן שאני לא אובייקטיבי (למרות שאין לי סיבה מיוחדת) אבל גם אתה כנראה לא אובייקטיבי, והזכרת כבר שאתה מתכנת בה עד היום. יוצא ש-PL/I מתוארת בערך כאילו היא ההחמצה הגדולה של עולם התכנות, שרק מקוצר ראות לא אימץ את הפיתרון המושלם לבעיותיו. אגב, שאלתי מתכנתים אחרים וקיבלתי תשובות כמו "שפה שמאפשרת להשתמש במילות מפתח כמשתנים היא חסרת-אחריות," כך שכנראה אני לא לבד בגישה הזאת

ברור שזאת החלטת עיצוב מודעת, שנבעה מהקשיים שמתכנים נתקלו בהם בקובול, ונבעה בוודאי מכך שהתחביר של שתיהן מבוסס אנגלית (בניגוד לתחביר המעט סימבולי יותר של שפות אחרות). אבל זאת החלטה עיצובית שהיא במקרה הטוב שנויה במחלוקת, כמו זאת שמתרחשת בשורות אלה. --אלעזר - שיחה 12:55, 17 במאי 2012 (IDT)

אחדד מעט את הסוגיה: בבואנו לבחון שפה, אפשר לבחון עד כמה היא מאפשרת תכנות טוב, ועד כמה היא כופה תכנות טוב. כאשר שפה אינה מאפשרת תכנות טוב (למשל שפה שאינה תומכת בנקודה צפה) זהו חיסרון ממשי; כאשר שפה מאפשרת תכנות טוב, אך אינה כופה אותו, יש שיראו זאת כחיסרון, ויש שיראו זאת כחופש. אישית אינני מרוצה מהאפשרות שלא להגדיר משתנים ב-PL/I (בעיני זו בעיה חמורה מאשר האפשרות להשתמש במילות מפתח כשמות של משתנים), אך על בעיה זו ניתן להתגבר באמצעות כתיבת נוהל המחייב הגדרה של כל משתנה. על חוסר היכולת לטפל בנקודה צפה (בעיה שאינה קיימת ב-PL/I אך קיימת בשפות אחרות), אין דרך להתגבר. נראה לי שבדיון במגרעותיה של שפה ראוי להתמקד במה שאינה מאפשרת, ולא במה שאינה כופה. בהערת אגב אציין שמוזר שמפתחי PL/I לא יצרו בה אופציות לחייב הגדרה של משתנים ולאסור שימוש במילות מפתח, אלה שתי אופציות שקל לממש אותן והיו מעניקות סיפוק רב לטהרנים.

ברוח דברי אלה שיניתי את המשפט "בין חסרונות השפה הבולטים הוא השימוש המוגזם בברירות מחדל" - זהו משפט בלתי נייטרלי בעליל, המשקף את טעמך (וטעמם של נוספים) בעיצובן של שפות תכנות. לטעמם של מעצבי פורטרן ו-PL/I זו יכולת חביבה של השפה, שמאפשרת כתיבה מהירה יותר. דוד שי - שיחה 04:29, 18 במאי 2012 (IDT)