מה אתם אומרים על פלטפורמות ה- Low-Code?

[chroot]

מה אתם אומרים על פלטפורמות ה- Low-Code?

ע"פ גרטנר:
“By 2024, low-code application development will be responsible for more than 65% of application development activity.

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

האם אתם גם רואים את הגידול בשימוש בתשתיות האלו גם לאפליקציות Enterprise גדולות?

 

[selalerer]

זה לא תחום מחוללי היישומים שחוזר על עצמו עוד פעם?

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

 

[user32]

וגם אז גרטנר כתבו אותו דבר

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

 

[choo]

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

&nbsp
זו טכנולוגיה שלא היתה שמישה בתקופת מחוללי היישומים (התאוריה כבר היתה קיימת, אבל החומרה לא איפשרה שימושים פרקטיים יותר מפיענוח אוטומטי של המיקוד על גבי מכתבים בדואר של ארה"ב).
&nbsp
יכול להיות שכבר עכשיו יושבות חברות סטארטאפ ב-stealth mode ומפתחות את "הדור החדש" של מחוללי היישומים תוך שימוש בטכנולוגיות החדשות להתגבר על הבעיות שחסמו את מחוללי היישומים בעבר.
&nbsp
נ.ב. במקרים נקודתיים כבר השתמשו בסוג מסויים של מחוללי יישומים כדי להחזיק מפתחים בעלי הכשרה חלשה יותר. הדוגמא הידועה ביותר בארץ היא....... אמדוקס. קבוצה בתוך החברה פיתחה "מחולל יישומים" יעודי למערכות ה-billing שלהם, וזה מה שאיפשר לחברה להחזיק מאות מפתחי תוכנה בתפקידי קסטומיזציה, שבהם אנשים בעיקר כותבים ביטויים רגולריים, קבצי xml וכדומה, ואחר כך לא מוצאים עבודה בשוק.

 

[user32]

אף אחד לא אמר שאין מקום לכלים האלה

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

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

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

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

 

[Nuke1985]

אני לא אהיה מופתע אם AI תחליף חלק ניכר מהמתכנתים

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

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

בקיצור עוד סיבה לא רעה (לדעתי) לחסוך כסף.

 

[יבגניי34]

מחשבים טובים בפתרון בעיות מוגדרות היטב (שח, גו)

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

 

[Nuke1985]

האפיון הוא בדרך כלל חלק יחסית קטן מהעבודה

לפחות מהניסיון היחסית קצר שלי.

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

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

 

[user32]

בדיוק

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

 

[AnarchistPhilosopher]

היה פעם סטריפ ב-xkcd על כך שהמתכנתים יתכנתו את התוכנות

שיביאו לסיום עבודתם.
&nbsp
אני מנסה לחפש את זה בגוגל אבל לא מוצא את המילים המתאימות...
&nbsp

 

[יבגניי34]

להקשיב לניתוחים של גרטנר בענייני טכנולוגיה זה כמו להסתמך על

יעקב ברדוגו להבנת הפוליטיקה בישראל.

לענינינו:

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

2. מה זה המטריקה הדבילית הזאת ״of application development %״

 

[הפרבולה]

תכנות ויזואלי קיים גם בסביבת פיתוח כמו VS

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

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

 

[BravoMan]

אוי ווי... כבר דיברנו על זה!

ראשית, מה שאתה מתאר אינו "תכנות וויזואלי".
למרות ש-MS אהבו לקרוא לכלים שלהם Visual לפני עשור או שניים, והם עדיין אוהבים את זה, בפועל התווית כמעת למגרי ריקה מתוכן.
&nbsp
תכנות וויזואלי הוא שאת הקוד עצמו - הלוגיקה, אתה לא צריך לכתוב, אלא גורר אובייקטים גרפיים שמייצגים מבנים ידועים מראש.
&nbsp
יש שפה חוצת פלטפורמות לזה:
https://scratch.mit.edu
&nbsp
יש אפילו גרסה שלה למיקרו בקרים סטייל ארדואינו, שם כל רכיב חומרה מיוצג כאובייקט.
&nbsp
כמובן, זה לא נועד ליישומים של ממש, אלא יותר ללימוד, ובעיקר לילדים.
&nbsp
לגבי בניית UI, אין דבר טיפשי יותר היום מבלנות UI בקוד.
אל תיקח את זה כעלבון אישי, אני לא קורא לך טיפש, אתה פשוט לא מהתחום.
&nbsp
כשבונים אפליקציה ללקוח, אפליקציה אמתית שהולכת למשתמשי קצה, ולא איזו תוכנה שרק צריכה להציג נתונים טכניים מרכיב חומרה ייעודי שהוא המוצר העיקרי, ה-UI הוא הכל.
&nbsp
הוא צריך להיראות טוב! עם אנימציות, עם תמונות שכל אחת במקומה, מעברים, גלילות, משיכות, וכו'.
&nbsp
לנסות לבנות מסך שנראה טוב בקוד, זה כמו משחק "הצמד את הזנב לחמור" (לא יודע אם יש גרסה ישראלית לזה).
https://en.wikipedia.org/wiki/Pin_the_tail_on_the_donkey
&nbsp
אתה מנסה לנחש מיקומים, לדמיין אותם בראש, ואז לתכנת מספרים קשיחים.
במקום פשוט לעצב את ה-UI עם כלים מתאימים.
&nbsp
אני אפילו לא נכנס לזה שהיום כל בניית UI היא "יחסית" או "אדפטיבית" כי צריך להתחשב בהמון סוגי מסכים.
&nbsp
בוא ניקח את הדוגמה הפשוטה שלך:
למה לכל הרוחות שתבנה כפתורים בלולאה? מניין יגיע טקסט לכל כפתור ואיך תצמיד לו את הקוד הרלוונטי?
&nbsp
אם יש אלמנט בממשק שמכיל יותר מ-3 אופציות, הוא כמעת אף פעם לא יהיה אוסף כפתורים.
הוא יהיה משהו דינאמי כמו תפריט או רשימה, משהו שבכל UI מודרני מטופל ע"י אובייקט יעודי, שמקבל "מקור מידע" ולפי אותו מקור מידע מייצר את האפשרויות הדרושות בזמן ריצה בלי שתצטרך לבנות אחת אחת בקוד עם לולאה משלך.
&nbsp
יותר מזה, הוא ידאג להתעדכן אוטומטית כשמקור המידע משתנה.
&nbsp
אני יודע שאתה תקוע עם כלים של MS משנות ה-90, עבדתי איתם לפני שנים ואני יודע שהם מייצרים הרגלים רעים, אבל הם גם מייצרים ממשק שהיום נחשב למכוער ולא מקצועי.
&nbsp
זמנם תם, ממליץ לך בחום לפתח הרגלים חדשים!

 

[יבגניי34]

זה בהחלט בשימוש לישומים של ממש labview או simulink ועוד רבים

 

[הפרבולה]

נכון זה לא בדיוק תכנות , אבל לדעתי יותר נוח לבנות

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

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

#define NUMOFBUTTONS 10

char *butontext[NUMOFBUTTONS] ={"func1","func2" ...};
char  *tips[NUMOFBUTTONS]={"this button do function 1", "this button do function 2",...};
unsigned int style[NUMOFBUTTONS]={ PUSH_BUTTON, PUSH_BUTTON ...};
FUNC *func[NUMOFBUTTONS] = {func1,func2};

int x=20, y=88, width=90, high=25; // location of the topbutton and size of each button
int space_between_buttons =30;
for int n=0; n<NUMOFBUTTONS; n++)
{
    pbutton[n] = new MyButton(x,y,width,high, butontext[n],tips[n],func[n],style[n] );
    y+=space_between_buttons;
 
}

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

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

 

[BravoMan]

ומה קורה כשאתה צריך לייצר ממשק בכמה שפות?

נניח שהמשתמש רוצה ששפת הממשק תהיה בהתאם לשפה שהוא בחר במערכת הפעלה?
&nbsp
אפילו MS בשנות ה-90 כבר המציאו resources לטפל בדברים כאלה

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

 

[הפרבולה]

אם צריך שפות שונות אז השמות מוגדרים

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

קל למצוא את הקוד של כפתור מסוים , מסתכלים על UI ועושים חיפוש על השם שמופיע על הכפתור ( או על הטיפ שלו ) בתוך הפרויקט ( ב VS יש אופציה לעשות חיפש על הפרויקט או על עץ או על ה solution כולו ), לחיצה על F12 על שם של פונקציה מקפיצה את העורך למימוש שלו או להצהרה עליו בהגדרת המחלקה וכו.

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

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

 

[BravoMan]

אמאל'ה...

אז אצלכם אפילו לא מפרידים את ה-GUI לקבצים נפרדים עם איזה naming convention?
&nbsp
אני אשכרה צריך לבצע חיפוש על טקסט כדי למצוא כפתור???
מה אם הטקסט על הכפתור הוא "OK"???
&nbsp
התיאורים שלך מזכירים לי יותר מידי את הצורה בה עבדתי כשלראשונה למדתי לעבוד עם ++Visual C גרסה 6 אי שם בסוף שנות ה-90.
&nbsp
זה היה סביר לפרויקטים אישיים קטנים, וגם לא הכרתי שום דבר יותר טוב מאז, אבל היום זה נשמע לי כמו להניע רכב עתיק בעזרת מנועלה מקדימה במקום לסובב מפתח.
זה עובד, אבל זה איום ונורא!
&nbsp
אתה לא רואה סיבוך גדול כנראה משום שמעולם לא היית צריך לבנות ממשק מעוצב באמת, וגם משום שאם משתמשים באותן פונקציות כל הזמן מתרגלים לריבוי פרמטרים.
&nbsp
בפועל, לא לטעות בבנאי עם 10 פרמטרים שרובם מאותו טיפוס זו אומנות, שכל כשל קטן בה מזמין באגים.
&nbsp
אגב, Ariel הוא לא פונט בגודל קבוע.הוא פונט בגודל משתנה זה בדיוק הנקודה שלו.
האות i והאות W לא תופסות אותו מקום.
והוא לא נמצא "בכל מערכת", הוא רק נמצא בכל גרסה של Windows.
&nbsp
אם חלילה ללקוחות שלכם יימאס להשתמש בה והם יחליטו לזוז, זו תהיה עוד צרה ב-porting.
&nbsp
מצד שני, יש לי תחושה שמבנה הקוד אצלכם הוא כזה שכל תזוזה משמעותית תהיה שכתוב מלא...

 

[הפרבולה]

ב GUI מסובכים אי אפשר להפריד באמת בינו לבין הלוגיקה

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

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

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

 

[BravoMan]

הפוך גוטה, הפוך

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