דיון - מחוללים, RAD ועוד

[דון פאקטו]

דיון - מחוללים, RAD ועוד

אחד הנושאים עליהם אני חושב כמן זמן רב הוא הנושא של פיתוח מהיר של יישומים. אם נעצור לרגע ונחשוב, אנחנו פעמים רבות חוזרים על אותו פיתוח שעשינו כבר בעבר, עם התאמות טכנולוגיות כאלו ואחרות. ברמה הנמוכה, בכל חברה קיימות ספריות אשר נועדו להתמודד עם הנושא של אובייקטים ופונקציות נפוצות. השאלה היא - מה קיים ברמה הגבוהה ? אני חושב ש-kawa בדף הקודם העלתה לדיון נושא דומה. אם אינני טועה, היא דיברה על פיתוח של מחולל של מחלקות, אשר יצמצם טעויות אנוש. אם ננסה להביט בצורה יותר רחבה, העוצמה של כלי שידע לחולל לנו יישומים שלמים, על סמך פרמטרים באשפים ותבניות, היא רבה מאוד. מספר נקודות למחשבה - לפני מספר ימים, IBM הכריזו על תמיכה מעניינת ב-RAD בגרסא החדשה של WebSphere Studio. למיטב ידיעתי, ב-NET. יש כוונה ללכת לכיוון, עם ה-Enterprise Architect (מישהו יודע מה אמור להיות ב-VS 2003?) מתחילים לראות גם ניצנים כאלו.

 

[אלדד27]

מחוללי יישומים הם דבר נחמד.

הם לא צריכים תוכניתנים מתוחכמים כי הם פשוטים מאוד; הם משיגים מטרה מאוד רחבה תוך זמן קצר מאוד; הם מאוד יעילים בהגדרתם. אבל הם לא מכסים הכל. למעשה, הם אפילו לא מכסים איזשהו רוב. כי אין מה לעשות - הטכנולוגיה רצה בטירוף קדימה, וצריך תוכניתנים אמיתיים שיישמו אותה. צריך תוכניתנים שיודעים לרדת לרמה בסיסית של אלגוריתמיקה, ולא רק להרים מסך שלך בשתי פקודות, אבל בלי שום שליטה על מה שיהיה במסך. באשר לרעיון שהעלתה KAWA, אז זה באמת מאוד נחמד, אבל בלתי ישים. אי אפשר לדעת מהן הטעויות של התוכניתן. אם הקומפיילר היה יכול לדעת מהן - הוא היה מזהיר אותנו בעצמו. באגים הם בדרך כלל לוגיים; בדרך כלל מדובר על כך שעשינו i=1 במקום i=0. שום קומפיילר בעולם לא יתריע בפני דבר כזה, מהטעם הפשוט שכדי שיקרה כזה דבר, הקומפיילר צריך *להבין* למה התכוונו בתוכנית שלנו. עוד לא הגענו לרמה כזו של בינה מלאכותית.

 

[דון פאקטו]

אתה מזכיר לי את אנשי האסמבלר.

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

 

[אלדד27]

מה שאתה אומר בעצם זה,

"אל תבלבל אותי עם העובדות". העובדות הן: 1. לא תוכל לכסות 100 אחוז בעזרת מחוללי יישומים. 2. הטכנולוגיה היום מקילה מאוד על חיי התוכניתן, אבל המון פעמים יש לך כל מיני "חידושים מלהיבים" שבפועל לא שווים כלום. בספריית MFC למשל יש חלקים נרחבים שאוי ואבוי למי שייגע בהם - כי הם כתובים רע מאוד, ובכל מקרה הם כל כך כלליים שהם דופקים לך את כל הביצועים של התוכנה. 3. אל תיפול בטכונלוגיה? לא הבנתי מה הקשר לטכנולוגיה... אולי אני ממש לא קולט, אבל לא הבנתי אותך. שמות לא משמעותיים או חוסר תיעוד הם שגיאה? ממתי אלו שגיאות? אולי זה לא בסדר לתכנת ככה, אבל באגים זה עוד לא עושה. ולמרות היותי חסיד של תיעוד מדויק ונכון, אני עדיין לא חושב שבאגים נגרמים על ידי חוסר בהערות. ועדיין לא השתכנעתי, ואני כן חושב שאיתור שגיאות לוגיות - כמו שמאתרת העין האנושית - הוא בהחלט תחום לעיסוק הבינה המלאכותית. חפש את הדוגמה המצוינת של אינגולמו בקשר ל-mutable איזה דף או שניים אחורה, ותראה שגם העין האנושית לא בדיוק תעלה על הבאג, שלא לדבר על קומפיילר או מין error seeker דמיוני שכזה...

 

[דון פאקטו]

יש לך שגיאת קומפילציה ../images/Emo26.gif

זה לא מה שאמרתי. אולי כדאי שתקרא שוב את הודעותיי. אבל לפני כן, אתייחס להודעה שלך. העובדות הן: 1. לא תוכל לכסות 100 אחוז בעזרת מחוללי יישומים. אתה טועה. זו לא עובדה כלל וכלל, אלא נבואה (וביננו, אתה יודע למי נתנה הנבואה). מזכיר לי אמירות רבות שליוו את התפתחות הטכנולוגיה (ובמיוחד המחשבים). 2. הטכנולוגיה היום מקילה מאוד על חיי התוכניתן, אבל המון פעמים יש לך כל מיני "חידושים מלהיבים" שבפועל לא שווים כלום. בספריית MFC למשל יש חלקים נרחבים שאוי ואבוי למי שייגע בהם - כי הם כתובים רע מאוד, ובכל מקרה הם כל כך כלליים שהם דופקים לך את כל הביצועים של התוכנה. ומה חדש בזה ? בכל דבר יש רע וגם טוב, אם ניצמד לקלישאה ידועה. בשפת התכנות החביבה עליך לא היית משנה דבר ? במכונית אותה רכשת, לא היית מכניס שינויים ? מהי התגלית, ווטסון ? 3. אל תיפול בטכונלוגיה? לא הבנתי מה הקשר לטכנולוגיה... אולי אני ממש לא קולט, אבל לא הבנתי אותך. שמות לא משמעותיים או חוסר תיעוד הם שגיאה? ממתי אלו שגיאות? אולי זה לא בסדר לתכנת ככה, אבל באגים זה עוד לא עושה. ולמרות היותי חסיד של תיעוד מדויק ונכון, אני עדיין לא חושב שבאגים נגרמים על ידי חוסר בהערות. אנסה להסביר שוב. זווית הראיה שלך מאוד טכנית וצרה. אלו רק דוגמאות. נסה להבין את הרעיון עצמו, אותו אני מציג. ועדיין לא השתכנעתי, ואני כן חושב שאיתור שגיאות לוגיות - כמו שמאתרת העין האנושית - הוא בהחלט תחום לעיסוק הבינה המלאכותית. לא על זה דיברתי, ידידי. אל תיצמד שוב ושוב לנקודה כה הצרה של איתור שגיאות לוגיות. נסה לעלות ל-level גבוה יותר, על מנת להבין את התמונה השלמה, את הקונספט.

 

[KKnDoIt]

בקשר ל- i=0 מול i=1

בקשר ל- i=0 מול i=1, יש איזו תוכנה שאמורה לעשות דברים דומים עבור C ו- C++. כלומר, התוכנה סורקת את הקוד ונותנת אזהרות (Warnings) אם נראה לה שכתבת משהו שיתפרש באופן שלא רציתה. יש להם המון כאלה אזהרות. הם מפרסמים כל חודש ב- DDJ (בגרסה המודפסת) חידה יפה, שבה מראים קטע קוד קצר ונאמר "התוכניתן ציפה לקבל... אבל הוא מקבל משהו אחר". מה הבעיה ? ואז הם אומרים שהתוכנה שלהם לוכדת את הטעות. אני לא זוכר את השם, אני אבדוק. זה קצת, מזכיר, לדעתי, את זה שאם בבורלנד (לפחות 3.11, שאותו אני מכיר), אתה רושם את הקוד הבא:

if (x = 5) { //... }​

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

 

[KKnDoIt]

מצאתי את השם:

לתוכנה קוראים PC-Lint, והנה הדף אם דוגמאות הקודם הקצרות: http://www.gimpel.com/html/bugs.htm

 

[אלדד27]

אז ככה...

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

unsigned int power(int x, int y) { unsigned int n, i; n = 0; for (i = 0; i < y; i++) n *= x; return n; }​

הקוד הנ"ל אמור לחשב את X בחזקת Y אבל הוא כמובן יחזיר 0, כי התוכניתן כתב n=0 ולא n=1. נכון, אני לא מקורי ומשתמש בדוגמה שהזכרתי קודם. אבל תאמין לי, מנסיון שלי בקוד שלי ושל אחרים, הדבר הזה לא נדיר כמו שהיית חושב שהוא עשוי להיות. במיוחד אתה יכול להיתקל בקטע הזה במשחקי מחרוזות, אגב. באגים כאלו שום כלי, חזק ככל שיהיה, לא יודע לפתור היום, כי פה השאלה היא שאלה של *הבנה*. PCLint אכן משפר משמעותית את האזהרות (ואגב, אני משוכנע שהוא בין היתר גם עושה הרבה כאב ראש על אזהרות סרק), אבל הוא לא יכול לכסות באגים לוגיים. אם שכחת לקרוא ל - RELEASE של איזשהו RESOURCE שאתה המצאת, שום כלי לא יעלה על זה. אין תחליף לתוכניתן המצוין. תמיד יהיה צורך בתוכניתנים מעולים שיודעים לדבג את הקוד שלהם ושל אחרים כמו שצריך, ואף פעם לא יספיקו הכלים האוטומטיים. הכלים האלו מקלים על העבודה ומאיצים אותה, אבל הם לא מחליפים את התוכניתן - ותוכניתנים גרועים עדיין יעשו קוד גרוע.

 

[gilad_no]

עוד הערות

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

 

[אלדד27]

נכון מאוד, מה גם שאני מאמין

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

 

[KKnDoIt]

אני לא בטוח

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

 

[KKnDoIt]

אני מסכים, אבל

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

 

[אלדד27]

זו לא השמה חוזרת -

(אלא אם כן טעיתי בקוד...) זו הכפלה, שפשוט בגלל שהיה שם 0 - תוביל ל - 0. והקומפיילר לא יכול באמת לדעת אם יהיה שם 0 או לא, מבלי *להריץ* באמת את התוכנה. יש בעיה שמוצגת באחד הקורסים באוניברסיטה (בד"כ חישוביות וסיבוכיות), שנקראת HALT. הבעיה הזו מקבלת בתוך קלט תוכנית וקלט לתוכנית, ומחזירה TRUE אם התוכנית עוצרת על הקלט הזה. הבעיה הזו מוכחת להיות בעיה בלתי פתירה. אי אפשר לדעת אם תוכנית תעצור או שתיתקע בלולאה אינסופית, לפחות לא לגבי תוכנית *כלשהי* (ברור שאם התוכנית מכילה רק x=0 וזהו, היא תעצור, אבל זה לא העניין כמובן). מצד שני, אם אתה - בתור אדם - תשב על התוכנית מספיק זמן, אתה תוכל לומר אם היא תעצור או לא. באותה צורה בדיוק אי אפשר לגרום לקומפיילר "להבין" למה התכוון התוכניתן. ראיתי את הבאגים החודשיים של PCLINT ואני לא מתווכח איתך - מדובר בתוכנה מאוד נחמדה, שעולה על הרבה טעויות נפוצות. לא רע בכלל, לכל הדעות; אבל מכאן ועד לבטל את הצורך בתוכניתן - נו, זה מדע בדיוני.

 

[KKnDoIt]

אני מסכים איתך

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

 

[אלדד27]

אבל מה הבעיה עם n=n*2?

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

 

[KKnDoIt]

נכון, זה רק שאלה של סמנטיקה.

גם זה:

for (i = 0; i < 10; i++) { n = n }​

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

 

[באפט]

RAD

אחת המטרות של הנדסת תוכנה, אם לא המטרה היחידה, היא להפוך את פיתוח התוכנה ל-cost-effective. לכל מיני קיצורי דרך כגון מחוללי מחלקות אין חשיבות כלל ברמת המקרו אלא אם כן הם באים כחלק ממתודולוגיה שלמה, כמו UML Modeling. כך או כך, אף כלי CASE לא מחליף את התוכניתן, אלא רק מקל עליו. IBM ו-MS לא המציאו את ה-RAD. כל emacs משומן היטב מתחילת העשור הקודם לא נופל מהם.

 

[דון פאקטו]

RAD אינדיד

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

 

[אלדד27]

הממממ

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

 

[דון פאקטו]

טוב, אז גם הערותיים מצידי.

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