שפות dynamic typing לפרויקטים גדולים

[fellow1]

השאלה אם זה יכול לנפח לך את הסגמנט של הטקסט

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

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

 

[ipv6]

auto "מוסק"

(איך אומרים בעברית deduced?) בזמן קומפילציה.
לפי סט ידוע של חוקים ולא מנפח את הקוד. מזמין אותך לקחת online compiler ולבדוק בעצמך בתור תרגיל (כתוב 2 פונקציות פשוטות שעושות בדיוק אותו הדבר אחת עם auto ואחת עם הtype מפורש ותראה מה האסמבלי שמתקבל)

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

#include <string>
auto randomOutput(bool b)
{
    if (b) {
        return std::string();
    }
    return 13;
}

int main()
{
    auto x = randomOutput(((rand() % 8) == 0)); 
    return 0;
}

נסה לקמפל את זה ותראה מה הקופיילר יגיד..

 

[fellow1]

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

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

 

[ipv6]

אין קשר ל-templates

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

 

[fellow1]

חוץ מזה שלפי הדוגמא שהבאת זה בדיוקsyntactic sugar לtemplate

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

 

[יבגניי34]

לא לכל שימוש ב auto יש מקבילה טמפלייטית

auto x = new Bloat<verbose, Somthing<some, thing>>();
״להחליף auto ב-T״ פירושו לכתוב עוד קוד חסר תועלת, להעביר את הקוד חסר התועלת ל header, לעשות לו include, ועוד מיני צרות שמזכירות לי כמה נהייתי מאושר מאז שהפסקתי לעבוד עם השפה הנוראית הזו.

 

[fellow1]

אוקי

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

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

וכן טמפלייטים זה אחד החלקים הנוראיים והבלתי קריאים בעליל בcpp ,נראה לי שכשימאס לי מnodejs ומc אעבור לjava או C#. נראה לי האיזון המושלם בין חופש להגנה שמקבלים מהקומפיילר.

 

[vinney]

סיוט

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

 

[S h a r k 1 8]

דווקא זה מסביר הרבה

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

 

[BravoMan]

לא התנסיתי בשפות אלה בפרויקטים גדולים

אבל יצא לי להשתמש בהם עם ספריות גדולות חיצוניות.
&nbsp
שם, חוסר טיפוס בפרמטר אמור להיות בעייתי יותר מאשר לא לדעת טיפוס משתנה בקוד שלך.
&nbsp
בהתחלה גם אני בכיתי על כל ענין ה-type, עד שהבנתי שזה סתם הרגל מגונה, שלא באמת חוסך טעויות ממתכנתים מנוסים, ומתכנתים לא מנוסים יכולים בקלות לירות לעצמם ברגל עם שפות בעלי strong static typing.
&nbsp
כך למשל ראיתי קוד Java של אדם, שלא אמור להיות "ירוק לגמרי", שהסטודיו זועק עליו שערך המשתנה לעולם לא נבדק ושיש בכלל if שתמיד יהיה true, ועדיין הקוד שם, והמבנה חסר הגיון.

 

[user32]

 

[שרעבי100]

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

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

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

 

[hadooper]

דעתי

היום מרבית מערכות התוכנה הן גם מבוזרות בתצורה כזו או אחרת, מייקרו-סרביסים, או לחילופין ווריאציה כזאת או אחרת של "עיצוב מונחה אירועים" וגם נשענות על ספריות רבות כרכיבי תשתית.
&nbsp
מה שאומר שלרוב פרוייקטים לא הופכים גדולים מדי מבחינת כמות הקוד שלהם, מכיוון שהמערכת עצמה "מפורקת" להרבה רכיבים ושירותים "קטנים" שהינם פרוייקטים בפני עצמם, כאשר כל אחד מהם הוא לצורך העניין git repository שאפשר לפתוח בסביבת פיתוח נפרדת.
&nbsp
באשר לשפות שהן dynamic typing, דעתי היא שיש להן מרחב בעיות שהן מתאימות יותר לפתור מאשר שפות אחרות. לכן השימוש בהן לרוב הוא תלוי בעיה קונקרטית. בשורה התחתונה, אפשרי בהחלט למצוא את הדרך הנכונה לעשות פרוייקטים גדולים גם בפייתון לצורך העניין.
&nbsp
בנוסף, אסור לשכוח שמי שמנוסה ורגיל לעבוד איתן, לא מתעכב כלל על דברים שציינת כמו בעיות שמתגלות מאוחר, או רק בזמן ההרצה.

 

[hadooper]

הייתי מוסיף

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

 

[nahsh]

שני הסנט שלי (למרות שיוצא שאני מסכים פה עם הרוב)

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

אבל תבדוק את שפת go.

 

[choo]

בדיקות אוטומטיות מרובות וכלי אנאליזה סטטיים *מההתחלה*

&nbsp
החשיבות של להתחיל עם זה מתחילת הפרוייקט, וברמה פשיסטית (אין אף warning, ובכל מקום שיש בעיה שלא ניתן לפתור בפרק זמן סביר, מסמנים יוצא מהכלל באותה שורת קוד, ולא מבטלים באופן גורף את הבדיקה הספציפית) היא אקוטית - אם מנסים להכניס דברים כאלו אחרי שהפרוייקט כבר צבר כמה שנים - מתחילים להתפשר על רמת ההערות שהכלי מספק, ומפסידים חלק מערכו.
&nbsp
אגב, הגישה הזו נכונה גם לדגלי קומפילציה בשפות מקומפלות - אם לא מתחילים מראש עם כל הדגלים המעניינים דלוקים - מאוד קשה להכניס אותם לאחר מכן.
&nbsp
לגבי בדיקות אוטומטיות - הן צריכות להתפרס על סוגי הקלטים השונים שכל פונקציה או תת-יחידה עשויה לקבל, כדי להבטיח טיפול נכון בכל אחד מהם. לא מספיק רק לעבור בכל שורת קוד (ושוב - זה רלוונטי גם לשפות מקומפלות). הבדיקות האוטומטיות צריכות להתחלק לשתי קבוצות - אלו שרצות תוך דקה-שתיים (בדיקות יחידה פרימיטיביות, שתופסות שגיאות בתוך הפונקציות ובתוך המחלקות), שאפשר להריץ אחרי כל שינוי בקוד, ואלו שרצות בצורה הרבה יותר מאסיבית, שתרוצנה בסביבת ה-CI (על כל commit) או בסביבת בדיקה ארוכה יותר שרצה פעם בלילה/סוף שבוע.
&nbsp
בסופו של דבר, איכות הקוד מושפעת מאוד מאיכות הבדיקה שמבצעים עליו המפתחים (אם תשאיר רק לאנשי הבדיקות למצוא את השגיאות מהסוג הזה, מצבך לא מוצלח. אם הם נתקלים בהן רק "פעם ב.." מספיק זמן - אפשר לחיות עם זה).
&nbsp
מצד שני, בשפות מקומפלות אתה נתקל בבעיות זמן ריצה מסוגים אחרים, שגם להם יש מחיר, וגם עליהן מתגברים בדרכים דומות.
&nbsp
בשורה התחתונה - חוששני שאני בעד ג'אווה כשלא צריך ביצועים יוצאי דופן או צריכת זכרון קטנה מאוד או התממשקות עדינה עם חומרה, אבל זה בגלל שכתבתי בה רק במשך חצי שנה, ולכן נחשפתי רק לחלק קטן מהצרות שלה

 

[יבגניי34]

הגישה הזו סבירה בדומיין והקשר מסויימים

וממש לא הגיונית כתשובה כללית לבעייה שלא נוסחה היטב.

 

[I130Form]

אז מה התועלת הגדולה בשפות דינמיות?

אם כמו שהסבירו כאן שפות dynamic typing מצריכות בדיקות נרחבות לאימות סוג הנתונים, מה ההבדל בין זה לבין static typing? במובן מסוים הסיווג הסטטי הוא בעצם בדיקות אוטומטיות שפשוט מוטמעות בקומפיילר במקום במערכת בדיקות נפרדת.
&nbsp
בשני המקרים צריך להתמודד לוגית עם מקרים של אי-תאימות בסוג הנתון, ובשני המקרים המרות טריוויאליות (לדוג' מספר שלם לנקודה צפה) מבוצעות ע"י הקומפיילר אוטומטית.

 

[user32]

מהירות, כיף, חיסכון בקוד

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

בשפה דינאמית אם יש לך טבלה עם 30 שדות אתה עושה load ומוחזר לך אובייקט עם 30 properties. זהו. וכשהטבלה משתנה הפלא ופלא יוחזר לך אובייקט בהתאם.
או קח בעיה יחסית פשוטה: ייצוג טקסטואלי של אובייקטים דו-כיווני (ייצוא-ייבוא). נסה לקרוא JSON או XML לתוך אובייקט ג'אווה ותגלה עולם שלם של טכנולוגיות וספריות שנועדו רק לפתור את הבעיה: איזה סוג טיפוס ליצור עבור כל שדה שנקרא?

 

[I130Form]

האם יש הבדל אינהרנטי בין הגישה הזו לMap<String,Object>?

הסכימה נחוצה כי בסוף התכנה כן מבדילה בין טיפוסי הנתונים השונים (לדוג' פונקציה מצפה למספר שלם ותיכשל אם תקבל מחרוזת). כלומר שפה דינמית פשוט מעבירה את שלב הבדיקות משלב יבוא הנתונים לשלב השימוש בהם.
&nbsp
בסקריפטים חד-פעמיים זה בסדר כי הקלט ידוע מראש והתיקוף שלו נעשה כבר בתוכנה אחרת. בתכנות שצריכות להתמודד עם קלט חדש (או כזה שלא תוקף עדיין) התחושה הייתה שעבודת התיקוף פשוט הועברה למקום אחר בפרויקט.
&nbsp
אנחנו צוות data science, אז תכנות הוא כלי עבורנו ולא המטרה הראשית, אבל הניסיון שלנו בפייתון הראה שבסוף מצאנו את עצמנו ממשים static typing ידנית (דרך unit testing או טיפול בשגיאות).
אני שואל כי אנחנו מתלבטים כעת לגבי הפלטפורמה הטכנולוגית לגרסה הבאה שלנו, ותוהים האם יש משהו שאנחנו מפספסים לגבי שפות דינמיות.