DCSIMG
March 2008 - Posts - Asaf Shelly

March 2008 - Posts

F#
Monday, March 10, 2008 7:24 AM

Hi all,

I just went over the list of lectures for this year's TectEd event in Israel and found a session about F#.

In trying to figure this out I googled for the term "F#" and got a link to Microsoft Research: http://research.microsoft.com/fsharp/fsharp.aspx

I remember visiting there in the last couple of years as an MVP. I still remember some of the craziest things that I have seen there (most are still under NDA). Most of the design that I have seen could have practical applications but it is obvious that the technology was the main issue here. On the other hand Microsoft Research got some of the best designs that Microsoft brought to the world sometimes developer misunderstand or even abuse.

This time I must admit that I found some confusing mix with F#.

Originally C# was created as a functional subset of C++, one that does not let developers write unreadably complex code. Now F# looks like it is taking the mathematical aspect of C\++. On the other way around C# takes the short and simple syntax of C\++ whereas F# uses something that looks like Basic or Pascal that has long lines and variables that are completely typeless.

See this for example: http://research.microsoft.com/fsharp/manual/getting-started.aspx

  let x = 3 + (4 * 5)
  let res = (if x = 23 then "correct" else "incorrect")

You can do the same with C++:

  x = 3 + (4 * 5);
  res = (x == 23 ? "correct" : "incorrect");

Are we not just going back to the mathematical C\++? That old forgotten language where everything is an expression and even " 1; " is a legal command... only we do that with VB syntax...

How about a language called C++# that does the same with C++ syntax?

 

Maybe I should add to my TechEd session about the .Net Parallel Extensions a sample code using F#.

Parallel F# has to be interesting to read, don't you think?

 

Asaf

 

MVP Summit
Thursday, March 06, 2008 12:24 AM

היי כולם,

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

בפוסט הקודם ציינתי שאני מעביר את ההרצאה ב- TechEd בנושא Multiprocessing ועל ה- .Net Parallel Extensions שמאפשרים מחשוב מקבילי ב- .Net.

בכנס בסיאטל יש לי פגישה עם צוותי הפיתוח והמנהלים שאחראים על ה- Parallel Extensions. חשבתי לאסוף משוב בזמן ה- TechEd ולהציג אותו לצוותים בסיאטל.

אם למישהו יש הערות, הארות, או הצעות, אפשר לשלוח אלי במייל, להשיב כאן בבלוג, או למלא טופס שאכין במיוחד ויחולק מחוץ לאולם כאשר אני מרצה באילת. ההרצאה היא בנושא ה- Parallel Extensions ובנושא Multiprocessing באופן כללי וגם המשוב יכלול שאלות בנושאים שקשורים ל- .Net וגם כאלה שקשורים ל- C++ ו- Win32 API.

 בברכה,

אסף

Parallel Computing
Monday, March 03, 2008 11:02 AM

שלום לכולם,

פוסט ראשון אז אתחיל במילה וחצי על עצמי. MVP בתחום מדיה דיגיטלית, מרצה מוסמך של WinCE 6, ספר Expert one on one Visual C++ שעוד לא יצא מתוך עצלנות לעשות review על ה- 600 עמודים שקיימים. סטארט אפ בתחום ניהול רשת, ונסיון בפיתוח של חומרה ותוכנה.

 עוד קצת עלי: http://www.facebook.com/profile.php?id=524097405

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

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

תובנה מעניינת. אני זוכר קורס בנושא שימושיות (usability - איך לתכן מוצר שיהיה שמיש). בקורס הוזכר מספר פעמים העקרון שאומר ש-'מצב' או state של האפליקציה חייב להיות ברור למשתמש ואמור להשתקף ב- GUI. לדוגמא מקש Enter משמש אותי כדי לרדת לשורה חדשה, וכשאני בתפריט אותו המקש בדיוק משמש אותי לבחירה. אלו הם שני מצבים שונים של התוכנה: מצב עריכה ומצב פקודה. למעשה כל תפריט הוא מצב שונה כיוון שבתפריט File לחיצה על A תבצע Save As ובתפריט Edit לחיצה על אותו המקש תבצע Select All.

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

במילים אחרות הרבה יותר קל לבצע עבודה שלא צריך לזכור בה מצבים.

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

משתנה מסוג מצביע ב- C/++ או אובייקט nullable ב- C#. יש לו שני מצבים בסיסיים: בראשון יש לו תוכן או הוא מצביע אל אובייקט, ובשני הוא NULL ואינו מצביע על אובייקט. לא תמיד מתכנתים מודעים למצבים האלה או מתייחסים אליהם. אם לחזור למשפט החצאים אז הדבר שקול לקיפול אוהל מתוך הנחה שהוא אינו מקופל מבלי לוודא.

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

הבעיה עם כל המצבים האלה היא שהם מתקיימים בזמן ריצה ולא בזמן הקידוד.

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

סוג אחר של 'מצב' או state הוא משתנים גלובליים. משתנה גלובלי הוא State של האפליקציה כולה ולכן מומלץ מאד שלא להשתמש בהם כיוון שבסופו של דבר יבוא המתכנת שיתעלם מאותו המצב או ישתמש בו לא נכון.

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

במקרה של משתנים גלובליים משתמשים באובייקט שמנהל את המשאב המשותף - המשתנה הגלובלי. קיימים פאטרנים רבים דוגמת Singleton וכד' שתפקידם ניהול אובייקטים גלובליים.

 

עכשיו אני מגיע לבעיה:

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

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

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

 

הפתרון הוא בשינוי תפיסה של עולם המושגים שלנו היום.

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

 

הרשו לי להפתיע אתכם בהרצאה שלי ב- TechEd בשם "Multiprocessing and the .Net Parallel Extensions"

עד אז תוכלו לבקר באתר שהקמתי לנושא: http://AsyncOp.com

 

בברכה,

אסף