הליכה לפתרון

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

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

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

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

נגיד וניקח את פרל כדוגמא. יש לפחות 3 דרכים שאני מכיר לסרוק את הספרייה. יש את File find Object של שלומי פיש, יש את File::Find שאותו שלומי החליף, אפשר להשתמש בכלל ב OpenDir וכמובן שאפשר להמשיך עם כמות הכלים למשימה זו. רק בשביל להתחיל לסרוק את הספריות, אנחנו צריכים להשקיע הרבה אנרגיה כאן (בשביל לדעת מה הרכיב המתאים לנו ביותר), ככה שהשפה למרות שמסוגלת לספק לנו את הכלים, אינה מתאימה למשימה שלנו כי היא מסבכת אותה יותר.

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

7 מחשבות על “הליכה לפתרון

  1. אורי

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

  2. סוייר

    האמת ש… בפרל יש את הדרך הישירה, שהיא כך:
    perl -ni -e 's/^#.*$//' filename
    ואם רוצים לעשות עותק של הקובץ על הדרך, פשוט עושים:
    perl -ni.bkup -e 's/^#.*$//' filename

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

    בעצם ה-overhead הוא לא על הכלי (שכן, זה לא יהיה איטי להחריד), אלא הוא על הזמן שתשרוף בזה שתמצא את השימוש בכלי מסויים.

  3. ארתיום

    אני, לא הייתי בוחר ב־C או ב־C++‎, ב־perl או אופילו ב־bash…

    הייתי בוחר ב־find שנועדה בדיוק למטרה הזו:

    find -lR 'some text' .‎

    בדיוק פותר לך את הבעיה…

    עידו, אתה מסתכל יותר מידי על השפה ולא על הבעיה. 😉

  4. שלומי פיש

    ראוי לציין ש-opendir עושה משהו שונה לחלוטין מ-File-Find-Object (ומ-File::Find שאותו F-F-O מכוון להחליף). מה ש-opendir עושה זה נותן את רשימת קבצים (ותת-המדריכים) בתוך המדריך. (בדומה ל-ls) לעומתו, File-Find-Object מאפשר לסרוק עץ שלם של ספריות, תת-ספריות ותת-ספריות וכן הלאה באופן רקורסיבי, ולפעול על כל רשומה שם, בדומה לפקודה find של יוניקס.

    כך ששני הכלים מיועדים לשתי מטרות שונות, ולא כדאי להתבלבל ביניהם.

כתיבת תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s