דא פיירפוקס

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

פודקאסט מספר 4 של רוורס עם פלטפורמה

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

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

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

תודה לפרנק - היה כיף ולהתראות בפעם הבאה.

פודקאסט מספר 3 של רוורס עם פלטפורמה

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

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

מקווים שתהנו - אנחנו נהנינו

איך כותבים קוד כשאין debugger

אני זוכר איך זרחו עיני בפעם הראשונה שפתחתי את הדיבגר (יש לזה מלה בעברית?) של בורלנד turbo-c וחוויתי את מה שהיה נדמה לי בזמנו כחוויה מיסטית. לראשונה בחיי יכלתי לראות למשתנים המקומיים שלי ישר בלבן של העיניים, יכלתי לבדוק את הערכים שלהם, לשנות את הערכים שלהם, והייתי בעננים! ולא רק משתנים מקומיים, כי אם גם משתנים גלובליים, רחמנא ליצלן. ולא רק משתנים - יכלתי גם לעשות single-step ואפילו break-point. מדהים!!! לא עוד טבלאות עם משתנים והרצות של התכנית על יבש עם עדכון ערכים סזיפי, לא עוד מחקים ממוללים על שולחני, דור חדש של כלי פיתוח עמד על מפתני - דור הדיבגר!

מאז אותו רגע ועד היום מים רבים זרמו בקישון, turbo-c התחלף ב Borland C++ 3.0 אשר התחלף בבוא העת ב Visual Studio לגרסאותיו השונות, ומאוחר יותר לכלי יוניקס/לינוקס כדוגמת GDB.

ואז גם הגיעו ימי ה Java העליזים עם Net-beans, Idea, Eclipse ועוד ועוד וכל סביבה חדשה כזו באה עם עושר נוסף של יכולות להסתכל לקוד ישר בעיניים ולא לפחד.
אפשר לחזור אחורה בריצה, אפשר להסתכל על כל חוט (thread) בנפרד, אפשר לעקוב אחרי ערכים של משתנה אחד ספציפי, ליצור break-point עם תנאים שונים, לדבג תהליך מרוחק שנמצא אולי ביבשת אחרת, ועוד ועוד ועוד - ממש לונה-פארק למתכנתים.

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

ואז באה הישועה ממקום בלתי צפוי. התחלתי לעבוד בשפה שאין לה דיבגר! התחלתי לכתוב ב actionscript2, שפה בעייתית מעוד הרבה סיבות אחרות, ובין השאר גם דיבגר אין לה. (ליתר דיוק יש, אבל א' הוא די פאתטי ו ב' אין מצב להשתמש בו בקונפיגורציה שבה אני עובד).
חצי שנה ראשונה קיללתי וקיטרתי - מי המציא את השפה המזעזעת הזו, למה הקומפיילר שלה כל כך מאעפן, ולמה לעזזל אין דיבגר?!
אחרי שלב הכעס בא שלב ההשלמה. הבנתי שאין דיבגר (וגם הקומפיילר לא משהו) אבל עם זה צריך להתמודד - ומאז יצאתי מחוזק.
אז איך כותבים קוד אם יודעים שאין דיבגר? איך חושבים עליו? איך משתכנעים שהוא רץ נכון אם לא רואים אותו צעד אחר צעד מתקדם בכיוון שייעדנו לו? שאלות אלה העסיקו אותי ולאט לאט גיליתי שאני משנה את הרגלי הקידוד שלי.
התחלתי לכתוב קוד כמו שצריך (טוב, אני מקווה...) להשקיע הרבה מאמץ במחשבה תחילה, לארגן את הקוד יפה יפה, לעשות תכנות דפנסיבי, כלומר אף פעם לא להניח כלום ותמיד לבדוק הכל ואולי החשוב מכל - לבדוק את האם-אמא של הקוד ע"י מימוש של עשרות או אולי מאות unit-tests. יצא שזמן כתיבת הבדיקות משתווה לזמן כתיבת הקוד האמיתי, ובמקרים מסויימים אני גם כותב את הבדיקות לפני המימוש (test driven development).

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

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

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

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

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




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

ואמרו אמן.

פודקאסט מספר 2 של רוורס עם פלטפורמה

אורי ואני הקלטנו אתמול את פודקאסט מספר 2 של רוורס עם פלטפורמה (www.reversim.com)

היה מאוד כיף והזמן רץ לו. תכננו לדבר על מספר נושאים ובסופו של דבר המשכנו רק את הנושא מהפודקאסט הקודם, קוד פתוח, ואת שאר הנושאים דחינו לשבוע הבא. יש הרבה על מה לדבר והחלטנו להגביל את עצמנו לחצי שעה בדיוק.
אז מה היה לנו? פיל אחד חמוד (HDOOP), שלושת אבות האומה: MapReduce, BigTable, GFS ועוד.
רסס ל איי-טונס (נשמע טוב במבטא פולני) נמצא כאן. (ב iTunes הולכים ל Advanced -> Subscribe to Podcast)

האזנה נעימה ומוזמנים להשאיר הערות.

נמצא - הפודקאסט העברי הראשון

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

כתגובה לפוסט קיבלתי כמה תגובות על פודקאסטים מעניינים וביניהם רציתי לציין לחיוב את הפודקאסט עושים הסטוריה עם רן לוי, אבל לצערי לא מצאתי את מבוקשי. לא מצאתי פודקסט ישראלי על עולם התכנה הישראלי.
בעקבות פוסט זה קיבלתי פניה מאורי להב - למה שלא נעשה פודקאסט משלנו?!!! אז ללא שהות (כמה שבועות...) הרמנו שנינו את הכפפה והתחלנו במרץ בבניית הפודקאסט הראשון שלנו: רוורס עם פלטפורמה!!!
בהזדמנות חגיגית זו אנו משיקים את השידור הראשון של הפודקאסט רוורס עם פלטפורמה (http://www.reversim.com) שבו אנו הולכים לדבר על עסקי התכנה - כלים, סביבות פיתוח, קוד פתוח, מסדי נתונים, שרותי אינטרנט וכו'. זה פודקאסט טכני שקהל היעד שלו הוא בעיקר מפתחי תכנה. רוב הזמן נהיה רק שנינו לבדנו מדברים על רשימת נושאים שהוכנה מראש, פעם בשבוע, חצי שעה, אבל אנו גם נשמח לארח דוברים ומרואיינים חיצוניים. אם יש לכם משהו מעניין להגיד, אם אתם מומחים באיזשהו תחום ורוצים לתרום נשמח לשתף. אם יש לכם שאלות אתם מוזמנים לשלוח אלי (ran את reversim נקודה קום) או אל אורי (ori את reversim נקודה קום) או להשאיר הערות בבלוג זה או ברוורסים. ואם אתם רוצים לדעת מה מקור השם רוורס עם פלטפורמה כדאי שתשיגו לעצמכם איזה iPod ותתחילו להאזין - שם כל הסודות נחשפים ;-)
אורי ואני מקווים שתהייה האזנה נעימה ונשמח לקבל תגובות.

על הקשר שבין אסתטיקה לפונקציונליות

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

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

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

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

private static int sendAnEmail(
 String from,
 List recepients,
 String subject,
 String body,
 List attachements,
 boolean actuallySend) throws Throwable {
List parts = new ArrayList();
// ''Build a sub-part for each attachment''
for (Iterator i = attachements.iterator(); i.hasNext();) {
 MimeBodyPart currPart = new MimeBodyPart();
 FileDataSource fds = new FileDataSource(i.next());
 currPart.setDataHandler(new DataHandler(fds));
 currPart.setFileName(fds.getName());
 parts.add(currPart);
}
// ''Build the message. add sub-parts if exist''
Session ses = Session.getInstance(new Properties());
Message msg = new MimeMessage(ses);
if (parts.size() == 0)
 msg.setText(body); // ''A single part message''
else {
 // ''A Multi part message''
 MimeBodyPart textPart = new MimeBodyPart();
 textPart.setText(body);
 Multipart mp = new MimeMultipart();
 mp.addBodyPart(textPart);
 for (Iterator i = parts.iterator(); i.hasNext();)
  mp.addBodyPart(i.next());
 msg.setContent(mp);
}
msg.setFrom(new InternetAddress(from));
msg.setSubject(subject);
msg.setSentDate(new Date());
Transport transp = ses.getTransport("smtp");
transp.connect(smtpServer, port, userName, password);
List toAddresses = new ArrayList();
for (Iterator i = recepients.iterator(); i.hasNext();) {
 String curr = i.next();
 InternetAddress[] temp = InternetAddress.parse(curr, false);
 toAddresses.addAll(Arrays.asList(temp))
}
InternetAddress[] arr = new InternetAddress[toAddresses.size()];
int j = 0;
for (Iterator i = toAddresses.iterator(); i.hasNext(); ++j) {
 InternetAddress curr = i.next();
 arr[j] = curr;
}
msg.addRecipients(Message.RecipientType.TO, arr);
if (actuallySend)
 transp.sendMessage(msg, arr);
transp.close();
return arr.length;
}

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

private static void sendEmail(
  final String from,
  final List to,
  final String subject,
  final String body,
  final List attachments) throws Throwable {
final Session s = Session.getInstance(new Properties());
final Message m = new MimeMessage(s);
setHeaders(m, from, to, subject);
setContent(m, body, attachments);
sendMessage(m, s);
}

private static void setHeaders(
final Message m,
 final String from,
final List to,
final String subject) {
m.setSentDate(new Date());
m.setFrom(new InternetAddress(from));
for (final String t : to)
  m.addRecipients(Message.RecipientType.TO, InternetAddress.parse(t, false));
m.setSubject(subject);
}

private static void setContent(
  final Message m,
  final String body,
 final List attachments) throws MessagingException {
if (attachments.size() == 0) { // ''No attachments to send''
  m.setText(body);
  return;
}
// ''Generate a multi-part message''
final MimeBodyPart textPart = new MimeBodyPart();
textPart.setText(body);
final Multipart mp = new MimeMultipart();
mp.addBodyPart(textPart);
for (final File f : attachments)
mp.addBodyPart(makeBodyPart(f));
m.setContent(mp);
}

private static MimeBodyPart makeBodyPart(final File f) throws   MessagingException {
final MimeBodyPart $ = new MimeBodyPart();
final FileDataSource fds = new FileDataSource(f);
$.setDataHandler(new DataHandler(fds));
$.setFileName(fds.getName());
return $;
}

private static void sendMessage(final Message m, final Session s) {
final Transport t = s.getTransport("smtp");
t.connect(smtpServer, port, userName, password);
t.sendMessage(m, m.getAllRecipients());
t.close();
}

ואני שואל: היא לא פשוט יפה? אתם לא פשוט רוצים להתחתן איתה?!

אז מה היה לנו פה? לפנינו פישוט בסגנון ספרטני. זהו סגנון תכנות מינימליסטי הדוגל בצמצום מספר הפרמטרים לפונקציה, צמצום ה scope של כל משתנה, צמצום אורך שמות משתנים ופונקציות, צמצום מספר ה control-structures כדוגמת if ו for ועוד צמצומים מצמצומים שונים. המטרה היא בסופו של דבר ליצור קוד שהוא יותר קריא ובכך גם יותר קל להבנה ולתחזוקה. ניתן לקרוא עוד על תכנות ספרטני כאן.

בגוגל עושים ביג-דיל מהקריאות של הקוד. כל מהנדס חדש חייב לעבור מבחן קריאות (readability) בשפה שבה הוא כותב ואם לא יעשה כך לא יוכל להגיש קוד בעצמו. לכל שפה יש מדריך סגנון (style-guide) שמגדיר בדיוק איך צריכה להראות פונקציה, איך בוחרים שמות, איך כותבים תיעוד, איך קוראים למשתנים איזה רווח לשים אחרי ה if ואיזה אחרי הפונקציה ועוד. כל מהנדס חדש עובר את הזובור הזה של קריאות שלאחריו הוא מאשפז את עצמו מרצון במוסד הקרוב.
בהתחלה חשבתי שקריאות היא דרך מקורית (וגיקית) של הוותיקים לתפוס תחת על הצעירים, להשפיל אותם וללמד אותם את מקומם. היום אני חושב שזו דרך לתפוס תחת אבל יש בזה בכל זאת קצת תועלת. היום אני עושה בממוצע שני code-review ביום, כלומר קורא קוד של אחרים, נותן הערות ובסופו של דבר מאשר או מבקש תיקונים ואני בטוח שבזכות זה שכולם עברו את הזובור הזה של קריאות הרבה יותר קל לי לקרוא קוד של אחרים. אני לא צריך להתרגל לסגנון אחר ולפעמים רק תוך כדי רפרוף קל וראשוני על הקוד אני יכול למצוא שגיאות.
מסקנת ביניים: יש ערך לקוד קריא ויפה ולו בכך שלאחרים יהיה קל יותר לקרוא את הקוד ולשפצו.

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

איך יודעים שהקוד יפה? הרי יופי זה עניין של טעם, לא? והלא אנחנו אנשי המדע והכל צריך להיות כמותי ומדוייק.
בתכנות הספרטני המתואר למעלה יש מספר מטריקות המעידות על "כיעור" של הקוד והמטרה היא לצמצם אותן. יש גם כלים שמתריעים בפני שגיאות סגנון כגון lint. כיום להרבה מאוד שפות יש כלי lint משלהם. ל HTML יש את ה W3C Validator שבודק נכונות של קוד HTML. ב HTML יש קשר הדוק בין נכונות לאסתטיקה.
ואנקדוטה נוספת לפני סיום: אחד המרצים שלי בטכניון אמר שהבשורה הגדולה של שפות תכנות, הסיבה שאנחנו כבר לא מתכנתים בבינרי, היא ששפת תכנות היא הפשרה בין מכונה לאדם. כלומר התכנית צריכה להיות מובנת לא רק ע"י המכונה אלא גם ע"י האדם שכותב ובמיוחד זה שקורא אותה. לדוגמא, חבר לעבודה אמר לי ש perl היא שפת write only.
ואולי עוד אנקדוטה אחת ודי, לא מזמן חבר שלח לי את הפוסט המצויין הזה שאומר שאילו שפות תכנות היו דתות אז C היתה יהדות כיוון שהיא עתיקה ומאוד מוגבלת, ++C היה איסלם כיוון שהיא מעמיסה עוד חוקים ומגבלות על גבי C ו perl הייתה voodoo.

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