לימודי תואר ראשון

[b o n f i r e]

לימודי תואר ראשון

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

 

[duducohn]

לימודים

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

 

[ddalus]

מישהו יכול להסביר לי?

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

 

[ייוניי]

אני חושב שהכוונה היא

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

 

[ddalus]

כנראה...

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

 

[duducohn]

עוד מספר הערות

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

 

[vinney]

הממם....

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

 

[duducohn]

חשבון

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

 

[vinney]

לא הבנת

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

 

[vinney]

*טמינת חול = טמינת ראש בחול ../images/Emo13.gif

 

[duducohn]

התמקדות ../images/Emo13.gif

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

 

[vinney]

welcome to real life

אני לא יודע מה עם הידע שלך בבסיסי נתונים, וגם לא ממש נראה כי אי פעם עבדת בשוק תחרותי מול בתי תוכנה גדולים. אתה מדבר במושגים של עסק קטן עם שרת שמשרת בסיס נתונים מגודל בינוני, עם שליפות פעם בכמה דקות. בעולם האמיתי יש בסיסי נתונים שמשרתים אפליקציה אחת, שבזמן נתון רצות עליו עשרות שאילתות, כשכל שאילתא עובדת על מליוני רשומות. עכשיו, בוא נראה איך אלגוריתם לא נכון דופק לך את העסק. נניח אלגוריתם מצליח לעבד 500 רשומות בשעה. ככה היה בפרוייקט המדובר. נניח שדרישת הלקוח תהיה עיבוד 1000000 רשומות בזמן סביר. לא דקה, לא שעה, אבל סביר. האם לדעתך 500 רשומות בשעה זה זמן סביר לאור הדרישה הזאת? כנראה שלא. אז צריך לטפל בבעיה, כולנו מסכימים. אתה טוען שתוספת RAM תגרום לאלגוריתם לשפר את עצמו עד כדי 500 רשומות לדקה? כי זה היה השיפור של האלגוריתם - בין 500 ל1000 רשומות לדקה, תלוי בסוג רשומה. אז אני אומר לך - אתה טועה. אתה טועה בהנחה הבסיסית שהאלגוריתם הלא נכון רץ בשרת. לא משנה כמה תשפר את הRAM של השרת, האלגוריתם בכלל לא רץ שם. אמרתי לך - השיפור היה באלגוריתם, השרת והשאילתא נשארו כפי שהיו. ולא משנה כמה תגדיל את הRAM של מחשב, הוא לא ירוץ פי 10 יותר מהר (תנסה בבית פעם), וגם אם כן - האלגוריתם השגוי היה משתפר אולי ב10% (בדוק). אז אל תזלזל.

 

[duducohn]

אענה לך יותר מאוחר

אהיה עסוק בשעות הקרובות

 

[duducohn]

להלן תגובתי

אתחיל בזאת כי נראה לי שאתה נסחף מעט לפן האישי וחבל. אני חושב שליבון הסוגיה הוא מספיק חשוב בכדי להישאר במישור הענייני. בתגובתך הקודמת ***כנראה***, אתה טוען ציטוט "... כשאני רואה במו עיניי "מתכנת מעשי" מציג בגאווה מערכת מידע קטנה ופשוטה שבה הרצה של שאילתה אחת לוקחת 20 דקות...". אני מקווה שאתה מסכים עימי שלאפליקציה מסוג כזה שבד"כ היא מקומית, מספיק בסיס נתונים כמו Access או מקביל לו. במצב כזה הרחבת הזיכרון בוודאות תפתור את בעיית זמן התגובה של השאילתא. הסיבה לכך היא שבשאילתות מהסוג הנ"ל מתבצעות המון פעולות צירוף (JOIN), שיוצרות מכפלות קרטזיות בין הטבלאות. מכפלות קרטזיות בין הטבלאות צורכות זיכרון ראשי (RAM) בטירוף. אם אין מספיק RAM אז מתחילות להתבצע פעולות דפדוף רבות בין הזיכרון הראשי לבין הדיסק הקשיח. לידיעתך, הפערים בין "הקריאה/כתיבה" מה- RAM למעבד לבין הקריאה/כתיבה מהדיסק הקשיח ל- RAM יכולים להגיע ל- 4 עד 5 סדרי גודל (בין 10000 לבין 100000). אגב, זו הסיבה המרכזית שמימוש בסיסי נתונים רלציונים התחיל רק בתחילת שנות ה- 80 למרות שמאמרו המפורסם של קוד פורסם כ- 10 שנים מוקדם יותר. בתגובתך הבאה ***המממ***, אתה טוען ציטוט "... אחרי שהשקיעו קצת זמן (לא הרבה, חודש-חודשיים עבודה אחרי פיתוח של שנתיים וחצי בפרוייקט) אותה שאילתא על אותו שרת רצה בעשירית זמן....". בתגובה שבאה אחר כך *** Welcome to real life ***, אתה טוען שהאלגוריתם לא רץ בשרת. אם האלגוריתם אינו רץ בשרת, אז מן הסתם זמן הפעולה של השאילתא נשאר כמות שהוא. זאת בהנחה, שאנחנו מסכימים כי שאילתא היא פעולה שמתבצעת על בסיס הנתונים שבשרת. לגבי הפן האישי, אני מציע שלא תסיק מסקנות על ידיעותיהם או אי ידיעותיהם של אחרים בנושאים שונים. זה אינו תורם מאומה לליבון הסוגיה, ההיפך הוא הנכון. אני מציע להתרכז בליבון הנושא ובטיעונים בעד ונגד, כדי שכולנו נרוויח. אגב, אני מלמד את הקורס בסיסי נתונים. לגבי העולם האמיתי. העולם האמיתי כולל מגוון רחב מאוד של בסיסי נתונים. המגוון הוא בחברות, במוצרים עצמם, בכמות הטבלאות והרשומות שמכיל כל בסיס נתונים כזה ובהיבטים נוספים. כמובן שהעולם האמיתי כולל גם מגוון לקוחות שנדרשים לאותו מגוון של בסיסי נתונים. אני מעריך בוודאות די גדולה, כי דווקא אותם לקוחות שבסיס הנתונים שלהם צריך לעבד מיליוני רשומות, הם אילו שעובדים עם אנשי מקצוע מסוג בוגרי מדעי המחשב או דומה, בין אם יש להם יחידת מחשב עצמאית ובין אם הם עובדים מול בתי תוכנה. כעת אני חוזר לטיעוני המקורי בניסוח משופר. *** שאילתא שרצה בשרת וזמן העיבוד שלה הוא ארוך, כמעט תמיד הפתרון האופטימלי הוא הרחבת הזיכרון *** חשוב להבין כי במדעי המחשב האקדמיה מזלזלת בתחום של מערכות מידע (עיבוד נתונים לשעבר). שפות תכנות כמו VB או מקבילות לה מהעבר הרחוק (קובול) הן מילות גנאי. את המונח כסף הס מלהזכיר (חוץ מהקורסים שקשורים לכלכלה). לבוגר מדעי המחשב שיוצא לעולם האמיתי, קצת קשה בהתחלה לקלוט כי השיקולים הדומיננטים הם כלכליים. לוקח זמן להחליף דיסקט, להבין כי הוא צריך לספק פתרונות ללקוח, לאו דווקא לחפש את האלגוריתם שיתן לו ציון גבוה יותר בקורס. עוד משפט לסיום, חלילה לי מלזלזל בבוגרי מדעי המחשב, נהפוך הוא ולו רק מהסיבה שגם אני בוגר מדעי המחשב.

 

[ddalus]

תיקון ותגובה

ראשית, את התגובה "כנראה.." כתבתי אני ולא vinney - אם הבנתי נכון את דבריך. אין לי מושג לגבי מאפייני המערכת שהוא דיבר עליה, אבל אני אכן התייחסתי ל-Access מקומי בתור דוגמא מאוד מייצגת. יתכן ש-vinney עושה הפרדה בין אלגוריתם פנימי בתוך הפליקציה שמשתמשת ב-DB, לבין עיצוב הייצוג של המידע ב-DB - בניגוד אלי - אבל רק הוא יוכל לאשר או להסביר... חשוב לי לסייג את עצמי ולהסכים מעט איתך: גם אם לפלוני אלמוני יש תואר "נחשב" במדעי המחשב, באמת אין שום הבטחה לכך שהוא יודע איך לתכנת בצורה טובה. אכן בוגרי CS נוטים לפעמים לזלזל (או חמור מכך - לא להבין) בחשיבות בחירת התשתית לפרוייקט. ומעבר לכך, הפרדיגמה של מדידת יעילותו של אלגוריתם *רק* לפי ניתוח אסימפטוטי עלולה לגרור חוסר יעילות "בעולם האמיתי" (וגם בעולם האקדמי שאינו חף מפרוייקטי תכנות!) אם זמן העבודה מנופח רק כדי שהקוד ירוץ *קצת* יותר טוב. ר"ל יש מקרים שבהם עדיף להשקיע חצי יום (או 3000 דולר על RAM, כדבריך) כדי לשפר זמן ריצה של אלגוריתם רק באחוז מסויים, אם כמות ה-data היא לא אסטרונומית, ולא להשקיע חודש כדי לשפר אותו בסדר-גודל "אד מיורם דאי גלוריאם". בקיצור, כאשר שמים דגש על יסודות מתמטיים *בלבד* ומתעלמים מהשאלה מתי הם לא רלוונטיים, עלול להיווצר חוסר יעילות מסויים. אבל זהו *רק* חוסר יעילות, ולרוב הוא פוגע בפרוייקט אך לא מכשיל אותו. מצד שני, חוסר יעילות הנ"ל מתגמד לחלוטין מול הבזבזנות המשוועת שבקצה השני של הסקאלה, שלרוב כן מפילה פרוייקטים שתוכננו בצורה עקומה. לכאורה "מתכנת מעשי" אמור להכיר את ההיבטים הטכניים של חומרות ותוכנות ספציפיים כתחליף להבנה אנליטית יסודית שלהם - כמו למשל "לעולם אל תכתוב ב-Access אפליקציה שרצה על יותר מטבלה אחת עם מליון רשומות". למעשה זה בלוף, גם כללי אצבע "מעשיים" כגון זה הוא לא מכיר משום ש"מעשיות" בהקשר הזה היא בדר"כ רק כינוי לעצלנות. והעצלנות הזו היא שורש התסכול הפרטי שלי, משום שהיא כר גידול פורה לקונספציות שגויות, כמו למשל "Access זה כלי טוב וזול לכל מערכת מידע". הזכרת למשל את חוסר היעילות של JOIN שנובע מכאך שהוא בעצם מכפלה קרטזית בין רשומות של טבלאות, ובאותה נשימה אמרת שזה בעייתי בגלל memory thrashing. לאדם "הלא נאור" שייקרא את זה יווצר הרושם שגם אם עיצוב ה-DB שלו גרוע (דוגמא: פרוצדורה שמבצעת 20 פעולות JOIN כדי להפיק תוצאה, כאשר האלגוריתם באפליקציה מריץ את הפרוצדורה הזו 5 פעמים לפני שהוא מחזיר תשובה), הכל יסתדר אם הוא רק יקנה עוד RAM. אין לו מושג למה הכוונת ב"מכפלה קרטזית". למה זה רע? מה הקשר בין "מכפלה" ל-"כרטיסיות"? לך תנסה להסביר לו *בלי* להגדיר מהי מכפלה קרטזית בתורת הקבוצות, וההבדל בין X בחזקת 2 ל-2 בחזקת X, שכמות הזיכרון שהוא יצטרך כדי לטפל ב-JOIN אסטרונומי על מספר טבלאות היא דמיונית (ואפילו לא בטוח שהיא תעזור בכלל, אם מערכת ההפעלה לא תתמוך בכל הזכרון הזה כמו שצריך). באופן דומה, וללא שום אוריינטציה מתמטית, גם אם תוריד פטיש 5 קילו על ראשו של "מתכנת מעשי" לא תוכל לגרום לו לכתוב תיעוד, או חס וחלילה קוד שיהיה קל לעדכון בעוד שנה, או משהו גנרי שלא מניח אינספור הנחות יסוד שתלויות בפלטפורמה שעליה נכתב הקוד המקורי... ואח"כ מתפלאים ש-80% המתוכנה בעולם לא מגיעה לכדי שימוש...

 

[ddalus]

אבל

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

 

[duducohn]

המשך

ראשית התנצלות. לא הבחנתי בכך שמדובר בשני אנשים שונים. ההקשר הוא אותו הקשר והתגובות בהמשך נראו לי כהמשך טבעי של התגובה שלך. בעיקרון אינני מתייחס ליישום ספציפי וגם כך טענתי בתגובתי הראשונה. אני מתייחס לגישה העקרונית, שאותה טענתי עוד בהתחלה. לגבי בוגרי מדעי המחשב, אני בהחלט חושב שהתואר שלהם נחשב משתי סיבות מרכזיות. האחת היא הקורסים התיאורטיים, בעיקר מתמטיקה וספיחיה שסטודנטים אילו צריכים ללמוד ולעבור (לדעתי אילו הקורסים הקשים ביותר באקדמיה, הצלחה בהם בהחלט מעיד על רמת האינטלגנציה של הסטודנט). השניה היא שבמדעי המחשב - כך לפחות זה היה אצלי - מלמדים לתכנת נכון, כאשר ישנו עונש, שהוא פגיעה בציון למי שלא עושה זאת נכון. בהמשך לאותה סוגיה, אולי לא הבנת אותי, אבל אני מאוד בעד מימוש של התיאוריות והמודלים השונים ביישום המעשי. הנקודה היא שצריך לדעת מה ניתן לממש, מה כדאי, היכן נגמרת התיאוריה ומתחילים האילוצים המעשיים. כאן אני מסכים עימך לחלוטין. לגבי "מתכנת מעשי", אני חושב שאולי קודם היינו צריכים להגדיר את המושג הזה. לגבי דידי קורס ב"תכנות מעשי" בתחום של מערכות מידע חייב לכלול ובאופן מעמיק את התיאוריה של בסיסי נתונים רלציונים. את האלגברה הטבלאית ואת שלושת השיטות למימוש המודל (צורות נורמליות, BC/NF ותרשימי ER). "תכנות מעשי" אינו מחייב לימוד והבנה של חשבון אינטיפיסימלי למשל. קשה לי להאמין כי הוא יצטרך לממש אלגוריתם של פונקציה טריגונומטרית כלשהי באמצעות הטורים האינסופיים של ? (הנה, גם אני אינני זוכר). 20 פעולות JOIN - אתה מכיר יישום ועוד מקומי ב- Access שמבצע 20 צירופים כאילו? שוב, בוא נחזור לעולם האמיתי ולא נמציא תרגילים לקורסים באקדמיה. אם בכל זאת אותו "מתכנת מעשי" היה עושה דבר כזה, הייתי מוריד לו פטיש של 10 קילו על הראש. הערה אחרונה לגבי התסכול. האמן לי, גם אותי זה מרגיז. להערכתי בשלב זה אין הרבה מה לעשות. מצד אחד העולם, במיוחד העיסקי רוצה פתרונות מהירים וזולים. מצד שני אין מנגנוני פיקוח ובקרה מוסדיים שיקבעו מה מותר, מה אסור ולמי מותר לעסוק בתחום מקצועות המחשב. אתה צריך להבין שכל המקצוע הזה הוא חדש יחסית (באקדמיה התחילו ללמד מדעי המחשב לפני כ- 30 שנה בלבד). לוקח זמן לגיבוש החוקים והתקנות. אפילו את לשכת מנתחי המערכות הקימו רק לפני מספר שנים. במחשבה נוספת, אולי כדאי לנצל פורום זה לקידום הנושא הזה. אסיים בהערה אישית. גם לי ישנן מידי פעם טעויות כתיב. לטעות זה אנושי. אני יכול להמליץ לך "לאמץ" איזשהו "דוס" (אין לי מילה אחרת, לכן אני מבקש סליחה ממי שאולי נפגע מביטוי זה). אם יש לך בעיה בשימוש, בכתיבה או בהבנה של מילה או ביטוי מסויים בעברית, קרוב לוודאי שהוא יוכל לעזור. מניסיוני הם הכי טובים בתחום.

 

[vinney]

אני כבר לא יודע למי מכם להגיב ../images/Emo13.gif

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

 

[ddalus]

ועוד דבר קטנטן

בהודעתך כתבת: "לגבי העולם האמיתי [...] אני מעריך בוודאות די גדולה, כי דווקא אותם לקוחות שבסיס הנתונים שלהם צריך לעבד מיליוני רשומות, הם אילו שעובדים עם אנשי מקצוע מסוג בוגרי מדעי המחשב או דומה, בין אם יש להם יחידת מחשב עצמאית ובין אם הם עובדים מול בתי תוכנה." הו, כמה הייתי רוצה שתהיה צודק בנקודה הספציפית הזו! זאת בדיוק הסיבה לכך שכתבתי את הפסקה האחרונה בהודעה "כנראה..." למעלה. לצערי, ההערכה שלך אינה מעוגנת במציאות המוכרת לי - וזו בדיוק הסיבה לשאלה המקורית שלי... למה זה בעצם ככה (ומשום מה, ביחוד בתחום ה-DB), אם ברור לכאורה שאנשים מקצועיים צריכים להיות אחראיים על סוגיות מקצועיות? אין לי שום דבר נגד אנשים שהם "לא איינשטיין". אין בזה שום קלון, בדיוק כמו שאין לי עודף מיוחד של כבוד לאנשים רק בגלל שהם יודעים לפתור אינטרגל. זה גם ברור שלא צריך מומחה עולמי ל-UNIX בשביל לכתוב shell script... הבעיה שלי היא עם העובדה שהעולם העסקי כיום נוטה ברוב המקרים להעדיף אנשים חסרי הכשרה לא רק כ"פועלים שחורים" אלא גם ברמת התכנון והבקרה הטכניים-מקצועיים של משימות. תוכניתן, כמשאב, לאו דווקא צריך להיות מודע *לכל* הסוגיות הסבוכות שנוגעות למוצר שהוא מפתח. ותוכניתן ללא ניסיון הוא באמת זול יותר, כאשר העבודה שלו מוכתבת לו עם דגשים והנחיות ספציפיים. באופן דומה, הדרג הניהולי הגבוה לא צריך להטריד את עצמו בבעיות מתמטיות אלא לקדם את ההיבטים הכלכליים של תפעול החברה (פלוס מינוס, זו לא הצהרה אבסולוטית)... אבל כאשר אתה מפקיד מישהו על התכנון של מערכת כזו או אחרת - בין אם הוא כותב אותה בעצמו, ובין אם אחרים מתחתיו כותבים אותה - לא עדיף להשקיע באדם עם ראיה רחבה והבנה יסודית של הבעיות הגלומות בתכנון? זה לא הגיוני גם מבחינה כלכלית שהמוצר הסופי לא יהיה מוגבל ומקרטע?

 

[ייוניי]

אני מסכים

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