בתשובה לאריק, 09/03/15 12:44
 |
|
 |
||
|
||||
 |
אתה אומר אם כך שהיעילות איננה בראש מעייניהם של המתכנתים? |  |
 |
 |
|
|
|
||
|
||||
|
לרוב היא לא. מהירות מעבד וזיכרון היום הם כל כך זולים (יחסית לעבר) שהדגש במוצרים כמו מעבדי תמלילים הוא הרבה יותר על חוויית המשתמש מאשר על יעילות. | |
|
|
|
|
|
||
|
||||
|
אם מהירות המעבד והזיכרון כל כך זולים, למה לוקח לו פאקינג 10 שניות להעלות מסמך? ומעבר לזה, כל חוסר היעילות הזה בסוף עולה בחימום יתר, בקיצור חיי מדף, וכן הלאה. תזכור שהיום גם הוורד לא עובד לבד, אנשים פותחים גם הרבה טאבים בכרום/פיירפוקס/אקספלורר, ובעבודה גם מריצים עוד כמה אפליקציות כבדות (שמן הסתם גם הן סובלות מסימפטום ה'למה לנו להיות יעילות כשכח העיבוד והזיכרון כל כך זולים'). בקיצור, אני לא משתכנע מהטיעון הזה. עדיין עצלנות ובזבזנות נראים לי יותר הגיוניים. |
|
|
|
|
|
|
||
|
||||
|
למי לוקח 10 שניות להעלות מסך? כן, ברור וידוע, יש גם את העלות של האנרגיה לצרכן... אבל בסופו של דבר, חברות תוכנה רוצות להרוויח כסף, אם יש לך שתי מעבדי תמלילים, אחד מאד יעיל והשני מאד נוח ויפה, אין ספק (מנסיון העבר, חברות ענק נפלו על אי ההבנה הזאת) מה הצרכנים יבחרו. כמובן שהבחירה להעדיף יופי ונוחות על פני יעילות היא לא בחירה תמידית - ברור שכשאתה בונה מסד נתונים, מנוע לג'אווהסקריפט או מערכת לעיבוד אותות, הדגש הופך להות על היעילות ולא על הנוחות. אבל באפליקציות שבנויות מסביב לחוויית המשתמש, כמו מעבד תמלילים, זה לא המצב (אגב, אני משוכנע שבכל מה שנוגע לשמירת המסמכים או קריאתם יש הרבה מאד עבודה על יעילות). מבחינת המשתמש, ההבדל בין מעבד תמלילים יעיל שבו לוקח חצי מילישניה לעבד תו חדש למעבד תמלילים מאד מאד לא יעיל בו לוקח שלוש מילישניות הוא בלתי נראה. לך תסביר לצרכן שאם תקנה את המעבד המכוער שלי ותחסוך לעצמך 3% מחשבון החשמל ותעלה את תוחלת החיים של המחשב שלך ב1.7%. אם אתה רוצה לכתוב מעבד תמלילים, ואתה עצלן מכדי לייצר אותו באופן יעיל, מה ימנע מחברה מתחרה פחות עצלנית לייצר מעבד תמלילים יעיל יותר. עצלנות היא אף פעם לא הסבר טוב למצב קיים בשוק תחרותי. |
|
|
|
|
|
|
||
|
||||
|
להגדיר את מעבד התמלילים של מייקרוסופט ככזה שמתחרה (או התחרה לאורך כל חייו) בשוק תחרותי (וודאי 'שוק תחרותי משוכלל') זה מאד רחוק מהאמת. וחוץ מזה, נוחות ויעילות אינן סותרות. חלק מהנוחות שלי זה שהמחשב שלי לא יתחיל לקרטע כשפתוחים לי עשרה טאבים בדפדפן וחמישה מסמכים בוורד. |
|
|
|
|
|
|
||
|
||||
|
זה היה נכון בעבר, לא עוד. וכמובן, המעבר מדגש על יעילות בלבד מול דגש על נוחות במגע עם משתמש הוא לא משהו שנמצא רק בשוק מעבדי תמלילים, זה נכון למערכות הפעלה, לדפדפנים, לנגני מוזיקה, לטלפונים חכמים, למשחקי מחשב ובכלל, בכמעט כל תוכנה שנמצאת במגע עם המשתמש (בלי קשר לשאלה אם יש לה או אין לה מונופול. השאלה היחידה, נראה לי, היא אם קבל היעד הוא יותר או פחות סבלני). תיקח, למשל, את הפופולריות של KDE וGNOME (היפות והמאד לא יעילות) מול LXDE וXFCE (המאד יעילות, בעיקר האחרונה, והקצת פחות יפות). נוחות ויעילות אינן סותרות בהכרח, וכשהן לא סותרות אז (אני מניח שגם במיקרוסופט כמו בכל העולם) מנסים למקסם את שניהם - בשביל זה אנשים שם מקבלים כסף - אבל לפעמים יש סתירה, וכשיש סתירה צריך לקבל החלטה. עצלנות היא עדיין הסבר לא סביר. |
|
|
|
|
|
|
||
|
||||
|
מדוע שתהיה? אני לא חושב שמישהו עדיין אומר למתכנת "ותעשה את זה עם פחות פקודות". סיפורי היעילות המופלאה של ימי תחילת המחשב האישי היו לדעתי שילוב של המגבלות הקשות מצד אחד (64k ראם, פחחח) ושל הגאווה האישית על המוצר מצד שני (הנה ווזניאק מספר איך עבד לשכלל את הלוח של האפל לחמישה חורים במקום שמונה בשלמות אמנותית כי "כאשר אתה עושה תכנון מעולה הוא מייצג את מי שאתה"). אבל על התוכנות של מייקרוסופט התלוננו שהן כבדות מדי עוד מימי MS-DOS |
|
|
|
|
|
|
||
|
||||
|
היום יש משאב מוגבל חדש: ככל שאתה משתמש יותר במעבד, אתה מקצר את חיי הסוללה. | |
|
|
|
|
|
||
|
||||
|
יעילות לא נקבעת על ידי מספר הפקודות. אלא על ידי משאבי החישוב והזיכרון של המוצר הסופי. | |
|
|
|
|
|
||
|
||||
|
פעם היינו שומרים טבלת מהירות ביצוע של פקודה ומתלבטים אם להשתמש ב SR או ב XR לאיפוס. | |
|
|
|
|
|
||
|
||||
|
זה כשעברתם מלגור במחילה ללגור באגם? ___________ נדמה לי שזו החזרת כדור, אם לא זכרוני לא הטעני בנמען :-) |
|
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |