חמש שאלות על עיצוב שפת תכנות

פילוסופיה מנחה

1. שפות תכנות לאנשים

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

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

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

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

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

2. עיצוב לעצמך ולחברים שלך

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

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

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

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

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

3. תנו למתכנת כמה שיותר שליטה

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

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

4. קצרות היא אחותו של הכישרון

הקיצור הוא לא מוערך ואף מבוזה. אבל אם תסתכל אל לבם של האקרים, תראה שהם מאוד אוהבים קיצור. כמה פעמים שמעתם האקרים מדברים בחיבה על איך, למשל, ב-APL, הם יכולים לעשות דברים מדהימים רק עם כמה שורות קוד? אני מניח שאנשים חכמים באמת אוהבים לשים לב לזה.

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

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

5. הכירו מה זה פריצה

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

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

בעיות פתוחות

1. איך לארגן ספריות גדולות?

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

2. האם אנשים באמת מפחדים מתחביר הקידומת?

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

3. מה אתה צריך עבור תוכנת שרת?

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

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

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

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

4. אילו הפשטות חדשות נותרו לגלות?

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

סודות לא ידועים

1. אתה יכול להשתמש בכל שפה שאתה רוצה

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

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

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

2. המהירות מגיעה מפרופילים

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

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

3. אתה צריך אפליקציה שתגרום לשפה שלך להתפתח

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

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

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

4. על השפה להתאים לכתיבת תוכניות חד פעמיות.

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

5. תחביר קשור לסמנטיקה

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

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

רעיונות שחוזרים עם הזמן

1. שפות תכנות חדשות

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

2. שיתוף זמן

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

3. יעילות

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

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

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

מלכודות ומלכודות

1. לקוחות

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

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

2. תכנות מונחה עצמים

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

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

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

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

3. עיצוב בוועדה

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

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

מקור: www.habr.com