הבנתי סוף כל סוף

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

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

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

אפשר לסכם את הדברים באמצעות כתיבת השורה

import self

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

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

בגלל שאני מאמין שצריך גמישות והרבה דרכים להשיג את אותו התוצר, אני מאוד נהנה לתכנת ב3 שפות (כלים):

  • פסקל מונחת עצמים
  • פרל
  • רובי

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

רובי על פניו נראת לא קריאה, והיא מכילה הרבה דברים שנראים להרבה אנשים מוזר כדוגמת:

def now!
  # some code
end

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

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

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

render(:page => ControllerName)

שווה ל:

render :page => ControllerName

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

הכוח הזה מספק הרבה יכולות מעניינות כדוגמת:

'A String!!!!1'.gsub(/[^a-z]/) do |x|
  case x
   when 'A'  : x = 'a'
   when "\s" : x = '.'
   when 'S'  : x = 'sh'
   else        x = ''
  end
end
=> "a.shtring"

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

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

במידה ולא אהבתם את מה שכתוב למעלה, אתם תמיד יכולים להשתמש בקוד הזה במקום:

'A String!!!!1'.gsub(/[A]/, 'a').gsub(/[\s]/, '.').gsub(/[S]/, 'sh').gsub(/[^a-z\.]/,'')

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

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

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

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

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

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!

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

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

12 מחשבות על “הבנתי סוף כל סוף

  1. queency

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

    מבחינתי קוד שאני כותב בפיתון צריך להיות מאד דומה
    לקוד שאני כותב בקובול

    קרא לי מוזר .

  2. ik_5 מאת

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

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

  3. Shai

    אולי נרד לקרקע קצת. מכל הדיבורים על "אפשרות בחירה", נשארתי קצת תוהה על מה אתה מדבר: בפייתון יש אפשרויות בחירה בלי סוף. נעזוב לרגע נקודות שלא ברור לי מה בעייתי לך בהן כמו "Complex is better than complicated" (בתרגום חופשי, "מורכב עדיף על מסובך"). בוא ניקח נקודה טכנית:

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

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

  4. ik_5 מאת

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

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

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

    אבל אני מתחיל להיכנס למחוזות שאני לא רציתי מראש בפוסט הזה.

    בקשר למורכב מול מסובך: מורכב בד"כ גורם לדברים להיות מסובכים. אם היית חייב משהו מורכב, אז בד"כ הוא לא קריא ומסובך לתחזוקה ותוספות.

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

  5. Shai

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

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

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

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

    האמירה "מורכב עדיף על מסובך" באה יחד עם "פשוט עדיף על מורכב". לא מכל מורכבות אפשר להימלט — אפילו ברובי.

    עם ה־Format String — אני מנחש שעשית משהו כמו

    "A %s string" % "formatted"

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

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

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

    מה רובי עושה, דרך אגב? איך הפירמוט עובד שם?

  6. מאיר

    מחרוזת היא רשימה (מערך) של תווים. כל מערך ניתן לאיטרציה.

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

    והאמת, לא ברור לי מה לא בסדר באלו שסימנת. אלו בדיוק הסיבה שאני מעדיף את פייתון על רובי.

    לא הבנת גם את הנושא של complex/complicated. אולי זה יסביר לך יותר טוב:
    "a girlfriend may be complex, but two girlfriends are complicated"

    להסברים נוספים:
    http://www.willmcgugan.com/blog/tech/2009/3/7/live-your-life-by-the-tao-of-python/

    ומפי האתון:
    Don't take these 19 aphorisms too seriously — tattooing them on your body is probably a bad idea, for example — but it's instructive to contemplate them. Some parallels can be drawn to the guiding principles of extreme programming, most notably the emphasis on "Do the simplest thing that can possibly work".

    http://www.python.org/dev/culture/

  7. ik_5 מאת

    שי, ברובי format string עם איבר אחד יכול להיות בצורה הבאה:

    "A %s string" % "formatted"

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

    "A %s string, #%d" % ["formated", 10]

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

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

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

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

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

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

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

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

  8. מאיר

    1. לא הבנתי איך הפורמט שונה מפייתון ?
    ‏‎>>> print "A %s string, #%d" % ("formatted", 10)
    A formatted string, #10

    2. הדוגאמ שהבאת לגבי camelCase לא רלוונטית, דוגמא נגדית שמפריכה זאת: ג'אווה סקריפט

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

    4. לא הבנתי מה הקשר של רווח לבן באמצע שורה. בפייתון הוא משפיע בתחילה, לא באמצע.

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

  9. ik_5 מאת

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

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

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

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

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

  10. מאיר

    1. הוא מתמודד כאיטרציה כאשר יש מקום לאיטרציה.

    2. בג'וואהסקריפט יש אותן מגבלות case, אך שם נפוץ מאוד השימוש ב-camelCase.

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

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

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

  11. ik_5 מאת

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

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

    var s : string

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

    קח כדוגמא את הפוסט הזה: http://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-oriented-language/ של יהודה כץ.

  12. מאיר

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

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

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

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s