מהי השפה הכי עתיקה, מוזרה, מגעילה או יוצאת דופן שקודדת בה?

יש אנשים שמתחשבים COBOL להיות שפה מוזרה כי בהתבסס על העיצוב של גרייס הופר עבור FLOW-MATIC,

להצהרות COBOL יש תחביר דמוי אנגלית, שתוכנן לתיעוד עצמי וקריא מאוד. עם זאת, הוא מפורט ומשתמש ביותר מ-300 מילים שמורות. בניגוד לתחביר מודרני, תמציתי כמו y = x;, ל-COBOL יש תחביר דמוי אנגלית יותר (במקרה זה, MOVE x TO y).

לחץ להרחבה...

משרד ההגנה. תמך בהופר מכיוון שיישומי "עסקים" בתחילת שנות ה-60 קודדו שפות אסמבלינג דור 2 על ידי מתכנתים שלא יודעים יותר מאלגברה יסודית, שהיו ב אספקה ​​נמוכה. עשיתי בערך שנה מזה בעצמי, אז למדתי COBOL בשבוע אחד ב-1969. בעיות התעוררו כאשר יישומים כאלה סבל.

יישומים כאלה סבל כי הם התגלמו מיוחד דרישות הארגון. הם היו צריכים הֲמָרָה, כפי ש כאן,

מאמצע 1994 ועד תחילת 1996 הייתי המתכנת הראשי בפרויקט להמרת 2100+ התוכניות של ניו יורק מערכת ניהול פיננסי משולבת של סוכנות לשירותי מידע פיננסיים ממערכת ההפעלה/VS COBOL של יבמ למערכת הניהול הפיננסית של יבמ COBOL II. הפרויקט, שלדעתי היה צפוי לקחת קצת יותר משנת אדם אחת, בסופו של דבר לקח בערך חמש שנות עבודה.

ראשית הרקע החשוף-מינימלי. FISA הוקמה בעקבות המשבר הפיננסי בניו יורק ב-1975 ("Ford to City: Drop Dead!") כדי לפתור שתי בעיות: (1) לא היה תקציב כלל עיר לעומת. מערכת הנהלת חשבונות בפועל. (2) סוכנויות עירוניות שונות שילמו לעובדים שלא היו להם סעיפי תקציב. FISA שכרה חברת ייעוץ בולטת לבניית שתי מערכות: (1) מערכת ניהול פיננסי משולבת ו-(2) ניהול שכר מערכת שבנוסף לעשות את כל הדברים הרגילים שמערכת שכר עושה - התחברה ל-IFMS כדי לוודא שאף עובד לא מתוקצב קיבל שולם.

שתי המערכות הללו נכתבו באמצעות מהדר OS/VS COBOL של IBM, על ידי צוותי קבלן שונים. הבעיה הבסיסית הייתה שבגלל שהמהדר OS/VS COBOL היה רק ​​גרסה מחודשת של הגרסה המקורית של IBM מהדר COBOL-65 שלפני ANSI-סטנדרטיזציה F-level, הוא יכול לטפל בהצהרות שהיו הרחבות של IBM ולא חלק ממנה CODASYL COBOL-65. חלק מההרחבות הללו מילאו צרכים מיידיים ש-ANSI סיפקה מאוחר יותר עם תחביר/סמנטיקה שונה, אך חלק מההרחבות הללו היוו רמת מקור תת-שפת ניפוי באגים (COBOL תוכננה במקור לכתיבת יישומי עיבוד אצווה) שמתכנתים לא ממושמעים לא יכלו להתאפק להשתמש בהם לצורך אי-ניפוי באגים קוד. IBM כתבה את המהדר התואם COBOL II ANSI-85 מאפס תוך שימוש בטכניקות CS שהתפתחו לאחרונה, ולא יישמה מחדש את ההרחבות ברמת F...

לחץ להרחבה...

יבמ מצאה צורך/מועיל להוסיף הרחבות ברמת F משנת 1965 בגלל הדרך החפוזה של אימוץ COBOL. אבל של COBOL תחביר מוזר בשפה האנגלית עשה את זה קַל כדי להוסיף הרחבות כאלה, רק דורש מילים שמורות נוספות.
.

אנאנקה אמר:

LabView היא השפה שבה השתמשתי שהכי פחות אהבתי. חלקית, מכיוון שבסיס הקוד שהצטברתי איתו כלל "מכשירים וירטואליים" (תצוגת מעבדה עבור "מודול") שדרשו שלושה מסכים שיתאימו במלואם למסך בבת אחת, והאם ה-IT או ה-PI שלי ישלמו עבור כל כך הרבה מסכים עבור דוקטורט נמוך סטוּדֶנט?

לחץ להרחבה...

זה סגנון קידוד LV מחורבן, אם כי נפוץ למדי. תתי שגרות, אנשים, תתי שגרות.

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

היו, למעשה, כמה אנשים שיכלו לעקוב "קוד ספגטי" עם הרבה GOTOs. אחד מהם היה מתכנת בשם ג'רי ב-NYC Transit Authority. אחר היה (אז קודם לאחרונה) קפטן גרייס מורי הופר, מהם שאלתי שאלה על GOTO ב-COBOL מהקהל במושב של ועידת המחשבים המשותפת של הסתיו ב-1973. תשובתה הייתה "הבעיה היא שאנשים לא לומדים מספיק גיאומטריה מוצקה". ברור שהיא לא הבינה שיש לה א כישרון נדיר.

בשנים 1983-1984 הייתי מתכנת בחברת מדעי המחשב, שבנתה מערכת שיתוף זמן מוקדמת ששפת המשתמש העיקרית שלה הייתה פורטרן 77. עשיתי כמיטב יכולתי לכתוב קוד מובנה, אבל פעם אחת הייתי צריך לשנות את התוכנית של מישהו אחר שנכתב בה בסגנון Fortran קלאסי. הוא נכתב עם המון ענפים תלת כיוונים, שהיה לי קשה מאוד לעקוב אחריהם.

DavidH אמר:

היו, למעשה, כמה אנשים שיכלו לעקוב "קוד ספגטי"

לחץ להרחבה...

אתה יכול לכתוב חרא בכל שפה, חלקם מתאימים לזה יותר מאחרים. עבדתי על פרויקטים רבים של C שבהם יש רק יציאה אחת מפונקציה, הכל מגדיר שגיאה מסוימת ועושה "סוף גטו;" אשר פותח הכל בצורה נקייה ובנקודה אחת. זה נפלא. ראיתי גם פונקציית קדם-מעבד שלמה בשם u, שאינה לוקחת ארגומנטים, אז אתה פשוט תקבל u; באמצע פונקציה ללא הסבר. שאלתי מישהו איפה זה מוגדר בקוד ומה זה עושה וקיבלתי תשובה "זה ידוע".

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

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

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

בתחילת שנות ה-80 שיחקתי עם כמה מחשבים ביתיים של 8 סיביות, רובם עם גרסאות אישיות משלהם של BASIC. המוזר ביותר היה כנראה זה ב-Sinclair ZX81.

בשנות ה-90 עשיתי כמה דברים ב-TCL. לאחרונה חזרתי; TCL עברה דרך ארוכה מאז, והיא מתאימה באופן מושלם לקבוצת הבעיות שאיתה אני עובד. אבל לא הייתי בקיא במיוחד עם TCL כבר אז, ושכחתי... בעצם הכל. אני מתכנת פסקל כבר הרבה מאוד זמן, והתרגלתי שיש לי כל מיני פונקציות ברמה גבוהה לשחק איתן. TCL שונה בהרבה באופן שבו היא עושה דברים. זה לא ממש קשה, פשוט נעשיתי מסודר בדרכי. TCL הוא זעיר, ויש לו טריקים מעניינים רבים בשרוול. ובשביל שפה שאמורה להיות כמעט מתה, חלקים ממנה בטוח מסתובבים; SQLite היה מטפל מסד הנתונים המקורי של TCL, והרחבות הגרפיות שלו הועברו כ-Perl/Tk ו-Tkinter תחת Python.

התעסקתי ב- FORTH, פעם. התלהבתי מהקונספט, אבל המימושים היו... גס. ולמרות שזה כנראה עבד טוב עבור בקרת מכונה, שלשמה זה תוכנן במקור, זה לא התאים לתוכנה בעולם האמיתי שרציתי לכתוב. TCL מזכיר לי הרבה את FORTH, אלא שאתה יכול לכתוב איתו תוכניות אמיתיות.

BitPoet אמר:

אתה יכול לכתוב חרא בכל שפה, חלקם מתאימים לזה יותר מאחרים. עבדתי על פרויקטים רבים של C שבהם יש רק יציאה אחת מפונקציה, הכל מגדיר שגיאה מסוימת ועושה "סוף גטו;" אשר פותח הכל בצורה נקייה ובנקודה אחת. זה נפלא. ...

...

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

לחץ להרחבה...

הבעיה הייתה ש- עד תחילת שנות ה-70-רוב תוכניות נכתבו בשפות assembly עבור מחשבי דור 2 או ב-Fortran - אשר עד ל-Fortran II היה ביסודו שפת הרכבה בלתי תלויה במכונה עם יכולות ביטוי מתמטי וטיפול במערך המושתלות עליה. כך מתכנתים רבים, לאחר שהיו כָּפוּי כדי לעשות שימוש נרחב ב-GO TO לפי השפה שבה הם קידמו, מַחֲשָׁבָה הם היו טוֹב בְּ- כתיבה וקריאה "לְחַרְבֵּן".

הבא הניסיון שלי למצוא באג חמקמק בתוכנית RCA שלב 3 שלי, I קרא את התקשורת של דייקסטרה משנת 1968 של ACM "הצהרת חזור אל נחשבת כמזיקה"מכתב והבנתי שאני לא כל כך טוב עם GO TO. אז כשלמדתי COBOL בשנת 1969, התוכנית הראשונה שלי פעלה לפי הנחיות "תכנות מובנה" @BitPoet מתאר כפי שצוטט לעיל.

עד אתמול בלילה הצלחתי לשכוח את עבודתי בת פחות משנה 1972-73 כאנליסט בקרת פרויקטים במחלקת הכספים. מקבוצת שירותי הניהול של NYSE. מלבד עיצוב מסד נתונים של פעולות מחשב עבור MIS מוצע של Finance, ניפוי באגים קיים של Finance Basic MIS תוכניות ופיתוח נהלים לחיוב זמן מחשב ושירותי מפתחים לפעילות של NYSE ו-AMEX מחלקות. המיזוג של הקבוצה שלנו לתוך SIAC ואחריו פיטורי כל עובדיה.

תוכניות MIS הקיימות של Finance Basic נכתבו PL/I—כנראה על ידי מהנדס מערכות של IBM. מה שהופך את השפה הזו לראויה להזכיר בשרשור זה, כפי שאומר מאמר ויקיפדיה בתת-סעיף "בעיות מתכנתים",

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

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

לחץ להרחבה...

התוכניות שירשתי היו צריכות להיכתב ב-COBOL, למרות של-IIRC לתוכנית שקראה זמן מחשב מקובצי יומן IBM OS/360 היו היבטים של שפת assembler. לא הייתי צריך לנפות באגים אלה - רק תוכנית חיוב זמן למפתחים. AFAICT הסיבה היחידה שהתוכניות הללו נכתבו ב-PL/I הייתה בגלל השפה הזו הייתה תוצר גאה של IBM.

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

ג'ונסונווקס אמר:

היה מסד נתונים בשנות ה-90 (אולי כבר בשנות ה-80) שהשתמש בשפת תכנות ויזואלית כמו תרשים זרימה. די כיף לשחק איתו, סיוט מטורף לעשות איתו משהו בעל ערך.

לחץ להרחבה...

זה לא באמת אותו דבר, אבל אולי אותו רעיון.

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

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

לגבי שפת התכנות בפועל, הכי קרובים שיש לי למוזרים ביותר הם Extendscript (דבר מסוג JavaScript לאוטומציה של מוצרי Adobe) ו-MEL (שפת סקריפטים משובצת עבור תוכנת התלת מימד Maya)