חוסר פתיחות מחשבתית

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

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

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

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

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

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

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

11 מחשבות על “חוסר פתיחות מחשבתית

  1. צפריר כהן

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

    כולנו יודעים מה זה קישור סטאטי ודינמי. לא חייבים להשתמש ב־gcc – אפשר להשתמש ב־tcc . לא חייבים להשתמש ב־glibc: יש גם uclibc, newlibc ועוד. לדוגמה: cygwin משתמש ב־newlibc ו־uclibc נפוץ למדי בתחום ה־embedded.

    אז יש לך כאן ספריה סטאטית אחרת. יופי.

  2. Shai

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

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

    אולי בכל זאת יכול להיות שאתה, ולא כל העולם, זה שטועה?

  3. elcuco

    … וסתם כי להצטרף לאמבוש עליך… עדיין לא ענית על נקודה אחת שהעלתי: מי ביקר את ספריית הריצה התקנית של פסקל שמקושרת סטאטית אל היישום? אני "מספיק" אנשים הסתכלו בה?

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

  4. ik_5 מאת

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

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

    למשל תת תוכנית שכתבתי לאחרונה בפסקל מתנהגת בצורה הבאה:
    ldd wavtogsm
    linux-vdso.so.1 => (0x00007ffff21fe000)
    libsndfile.so.1 => /usr/lib64/libsndfile.so.1 (0x00002b81b8c4d000)
    libm.so.6 => /lib64/libm.so.6 (0x00002b81b90d2000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b81b9353000)
    /lib64/ld-linux-x86-64.so.2 (0x00002b81b8a32000)

    שים לב שהיא מקושרת דינאמית לספריות (כולל libc). זה כי היה צורך לקשר דברים בצורה דינמית !
    ד"א:
    file wavtogsm
    wavtogsm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped

    ככה שאתה יכול לראות שיש התאמה לצרכים שלך. אבל בשביל writeln אין לך צורך כזה. גם לא בשביל Getmem או אפילו GetHostName.

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

    במקום לנסות להוכיח לי שאני טועה בתאוריה, בבקשה תקחו את FPC, תהדרו דברים עם smart link (כי ככה צריך לעבוד) ותוכיחו לי שאני טועה אחרי שאתם מנסים.

  5. Shai

    עידו,

    א. אתה עושה עניין גדול מזה שההגדרה של WriteLn נמצאת בתוך ה-binary של הקומפיילר ולא בקובץ ספריה נפרד, ואולי בשימוש היא אפילו inlined. השני נחמד, הראשון מפוקפק, בכל מקרה אין כאן עניין גדול.

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

    כדי להוכיח שכולם (במיוחד ארתיום) טועים, הניסוי שאתה (כן, אתה) צריך לעשות הוא כזה:
    1. בנה לך Hello World שלא יוצא מיד (כדי שיהיה פעיל מספיק זמן למדידה). צור, נאמר, עשרים עותקים של ה-executable. עותקים פיזיים נפרדים.
    2. מדוד את צריכת הזיכרון כאשר כולם רצים ביחד, לא ע"י הנתונים של כל תהליך בנפרד, אלא ע"י השוואת הפלט של free לפני ההרצה ובמהלכה — רק כך תקבל את צריכת הזכרון הנכונה של כל המערכת. חזור על הבדיקה כמה עשרות פעמים, כדי לנטרל אפקטים של תהליכים אחרים שעולים ויורדים במערכת.
    3. פעם עם פסקל, פעם עם C.

    חוצמזה, שוב: יש בעיה עם עדכונים. אם יתגלה buffer overflow במימוש של ReadLn, למשל, בהנחה שהיא מקושרת\inlined כמו WriteLn, מתחזקי ההפצה יצטרכו לעדכן לא רק את הקומפיילר או הספריה שלו, אלא את כל התכניות המקומפלות.

  6. ארתיום

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

    אבל כדי להראות משהו שונה: יש לתת הוכחות — הוכחות מספריות מסודרות ומדויקות.

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

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

    זכור, רוב החבר'ה פה מאוד opinioned.

  7. מאיר

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

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

  8. פינגבק: FPC Static’s vs GCC Dynamic’s פרק אחרון « לראות שונה

להשאיר תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s