הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
Mono או לא Mono, זאת השאלה...
לאחרונה יש עשרות כתבות ודיונים בנושא Mono... הנושא מזכיר לי מאוד את "מלכודת ה־Java המפוסמת" שהייתה רלוונטית עד ש־Java שוחררה תחת רישיון חופשי ע"י Sun... רק שפה יש גם כמה נקודות נוספות:
| תכונה | Java | C# |
|---|---|---|
| מימוש סטנדרטי "דה־פקטו" | Sun | Microsoft |
| פורטביליות | גבוהה נתמכת ע"י Sun | רק עם מימוש של Mono |
| פטנטים | ??? | ישנם |
| מימוש חופשי שפת התכנות | מלאה | חלקי 2.0 מול 3.5 |
| מימוש חופשי של ספריה | 1.4--1.5 לעומת 1.6 | חלקי |
למעשה, היום, אם מסתכלים על Mono... אז יש איתו הרבה יותר בעיות בהשוואה למה ש־Java הייתה פעם (וגם זה כבר לא רלוונטי לאחר שחרור Java תחת GPL).
אבל נעזוב כרגע נושא של פטנטים, בעיות של שימוש בטכנולוגיה לא חופשית. יש בעיה הרבה יותר פרקטיות ומשמעותית:
- Mono, עם כל הכבוד לו (ויש כבוד) נגרר ומפגר בצורה משמעותית בהשוואה של טכנולוגית .Net של Microsoft. המצב של ספריה עוד יותר בעייתי. למעשה, היום להריץ יישום C# כפישהו מ־Windows על Mono לא יותר פשוט מאשר להריץ אותו על wine (אם לא יותר קשה).
- השחקן הראשי בפיתוח טכנולוגיית Net. לא מעוניין בהשקעה בפיתוח ב־Mono. למעשה, Microsoft לא מנסה להפוך את הטכנולוגיה שלהם ל־Cross-Platfor אלא רק "עוזרת" לעתים רחוקות לפרויקט Mono כשזה מאוד חשוב להם (כמו, תמיכה ב־SilverLight שמאפשרת להם להגיד שזאת טכנולוגיה Cross-Platform).
- מעבר לכך ש־C# היא שפה קצת יותר נחמדה מ־Java היא לא נותנת הרבה. רוצים משהו קל באותה מידה? תשמשו ב־D, Java או ב־Vala. לפחות הן טכנולוגיות בפני עצמן.
במילים אחרות... ל־Mono יש הרבה בעיות מעבר לבעיות המשפטיות, אז למה לעזאזל לתמוך בו? בשביל שפת תכנות נחמדה שיש רבות כמוה, או בשביל הספריות שלה שתפורות ל־Win32API?
גם אני נגד Mono... רק אולי גם מטעמים אחרים
תסריט פיתון להחלפת namespace של Boost.
הכנתי תסריט קטן שמאפשר שינוי גורף של Namespace עץ הקוד של Boost ל־Namespace חילופי כדי למנוע התנגשות בין גרסאות Boost שונות: http://art-blog.no-ip.info/files/rename.py.
הרצה: ./rename.py /path/to/boost/tree new_namespace_name
עכשיו כל ה־defineים וכל הסימבולים יימצא ב־namespace אחר ואפשר יהיה לבנות רכיבים ללא תלות בגרסת Boost.
הערות:
- השימוש על אחריותכם, גם אם זה יאכל לכם את החתול או יהרוס את כל הקוד במחשב שלכם.
- הוא עדיין די ראשוני, אבל הצלחתי לקמפל רוב הספריות החשובות ולהריץ כמה regression tests.
את התסריט כתבתי לפתרון אפשרי לבעיה שהצגתי במאמר הקודם
דברים שלא נאמרים על Boost.
או ליתר דיוק, לא מודגשים לגביו.
http://boost.org היא אחת הספריות הפופולריות ביותר ב־C++, היא מהווה ל־C++ מה ש־JDK מהווה ל־Java, מה ש־RTL ו־FCL מהווים ל־FreePascal, היא מה ש־Python Standard Library מהווה ל־Python.
היא, למעשה, הספרייה שנותנת את הכלים העשירים הנדרשים לעבודה, מעבר לגרעין הקטן של השפה. בפרט:
- תמיכה ב־Threads.
- עבודה עם socketים.
- כלי עיבוד טקסט.
- ביטויים רגולריים.
- עבודה עם זיכרון משותף.
- ועוד.
היום, היא בהחלט מהווה דה־פקטו סטנדרט בתחום C++, כך שחלקים גדולים ממנה כבר נכנסו ל־STL הבא של C++.
יחס עם זו. יש לה חיסרון אחד עצום שבמקרים רבים לא מורגש ע"י מפתחי יישומים, אבל כן מורגש ע"י מפתחי ספריות ו־toolkitים שונים. החיסרון הוא העדר תאימות כלשהי של ABI לאחור והעדר תאימות מלאה של API לאחור.
המשך...השוואת FPC ושפות אחרות
נתחיל מהטבלה שמשוואה מספר שפות תכנות פופולריות: Python, Java, C, C++ ו־FPC. כאשר אני מתמקד במספר רבדים: תכונות שפה מרכזיות, סגנונות פיתוח ותכנות אפשריים, ספריות וספקים.
השוואה לפי תכונות:
| Feature | Python | Java | C | C++ | FreePascal |
|---|---|---|---|---|---|
| Core: | |||||
| Memory man. | Automatic | Automatic | Manual | Semi-Automatic | Manual |
| Resources man. | Automatic1 | Manual | Manual | Semi-Automatic | Manual |
| Inheritence | Multiple | Sinlge | No | Multiple | Single |
| Polymorphizm | Duck | Dynamic | No | Dynamic+Static | Dynamic |
| Reflection | Yes | Yes | No | No | No |
| Language Features | |||||
| Generic Programming | Irrelevant | Limited | No | Turing Complete | Limited |
| Generic methods | Irrelevant | Yes | No | Yes | No |
| Requires interfece | Irrelevant | Yes | - | No | No |
| Functional Programming | Yes | Very Limited | No | C++03 Limited C++0x Full | None |
| Libraries: | |||||
| Standard: | Rich | Rich | Poor | Limited | Rich |
| conteiners | Yes | Yes | No | Yes | Yes |
| threading | Yes | Yes | No | No | Yes FCL |
| GUI | Yes | Yes | No | No | Yes LCL |
| 3rd party libs.: | Rich | Rich | Rich | Rich | Poor |
| Other: | |||||
| Standards | None | Yes | Yes | Yes | Outdated |
| Implementations: | CPython, Jthon, IronPython | GNU, Sun, IBM | Lots | Many: GNU, MS, HP, Sun, Intel... | Single |
| Defacto-Vendor | Yes: CPython | Yes: Sun | None | None | FPC |
| Performance | Poor | Medium | High | High | High |
הערות:
- רק ב־CPython.
סיכום:
- Python: נותנת לעבוד עם כל סגנונות פיתוח אפשריים, קל לפיתוח וניהול משאבים, אבל סובל משתי בעיות עיקריות: ביצועים ו־vendor lock in.
- Java: שפה יחסית מגבילה מבחינת הגישה שלה, אבל בטוחה לפיתוח ותכנות בזכות: GC, ספריה סטנדרטית מאוד עשירה פשטות השפה.
- C: שפה שכמטע ולא מספקת כלים "מודרניים"... כבודה במקומה מונח, ועדיין יש לה המון יישומים במיוחד בתחום embedded, או כל תחום אחר בו צריך לרדת לרמת תכנות נמוכה ולשמור על קומפקטיות וקריאות של הקוד.
- C++: שפה מאוד עשירה, הרכיבים המודרניים היחידים שחסרים לה זה: העדר Reflection, העדר GC מלא (אם כי ב־C++ RAII מחליף אותו בהצלחה) ואולי צורך בספריות צד ג'. כמובן עם הכוח בא גם החיסרון: שפה מסובכת שלוקח זמן ללמוד אותה לעומק ולהבין את הרבדים השונים שלה.
- עכשיו הגיע תורה של FPC: היא נמצאת איפשהו בין C לבין Java:
- מצד אחד, אין לה GC ומצד שני אין לה גם RAII שיש ב־C++, ניהול המשאבים שם ידני לחלוטין ממש כמו ב־C.
- יכולות הירושה מוגבלות לירושה בסגנון C#/Java.
- תמיכה ב־Generics מוגבלת, אין תכנות פונקציונלי (במובן lambda calculus) וגם אין Reflection.
- ספריה סטנדרטית די עשירה (אם לוקחים גם FCL ו־LCL), אבל העדר ספריות צד ג' כואב, הרבה יותר
נשאלת השאלה: מהו הערך המוסף ש־FreePascal נותנת מעבר לתחביר שנחשב לקצת יותר קריא? נדמה שלא הרבה.
לרגל שחרורו של gcc-4.4... חידושים ושיפורים.
לפני כחודש שוחררה גרסה חדשה של gcc: 4.4. אחד הדברים המעניינים זה התקדמות בתמיכה בתקן C++ החדש C++0x. הנה כמה תכונות מאוד מעניינות שכבר מזמן חיכיתי להן:
סוף־סוף, הגיע אחת התכונות הנחשקות ביותר --- תמיכה ב־auto, שחוסכת המון הקלדה מיותר ומקלה בצורה משמעותית על כתיבת קוד בלתי תלוי בקונטיינרים. לדוגמה, היום כך כותבים לולאה שמדפיסה איברי הרשימה:
for(list<int>::contst_iterator p=numbers.begin();p!=numbers.end();++p) { cout<< *p <<endl; }ואם רוצים לשנות את סוג הקונטיינר מ־list ל־vector צריך לשנות את
listל־vectorבלולאה. עם טיפוס auto זה מתקצר בצורה משמעותית:for(auto p=numbers.begin();p!=numbers.end();++p) { cout<< *p <<endl; }ובנוסף ל"קיצור" הכתיבה, אין שום אזכור של סוג הקונטיינר בלולאת for.
טיפוסי תווים חדשים. בסטנדרט הנוכחי יש בעיה משמעותית בהגדרת תווי unicode, או ליתר דיוק העדר הגדרה ראויה שלהם. כך
wchar_tלמעשה יכול להיות בגודל של 32 ביטים, 16 ביטים ואפילו 8 ביטים. למעשה, בסביבת Windows, wchar_tהוא בגודל של שני בתים ומייצג utf-16 (או ucs-2), כאשר בכל סביבות ה־UNIX, wchar_tמייצג נקודת קידוד בודדת והוא בגודל של 32 ביט. זה יוצר לא מעט בעיות בטיפול במחרוזות unicode. כי הקידוד של std::wstring לא ברור.התקן החדש הגדיר שני טיפוסי תווים חדשים:
char16_tו־char32_tשמונעים את האי בהירות בנושא. כך שהעבודה עם std::u16string ו־std::u32string הופכת להרבה יותר שקופה. כך, בנוסף הוגדר ייצוג חדש למחרוזות:std::string normal="שלום"; // encoded as 8 bit std::wstring wide=L"שלום"; // utf16 or utf32 depending on your OS std::u16string utf16=u"שלום"; // utf16 encoded std::u32string utf32=U"שלום"; // utf32 encodedכמובן, לא צריך לשכוח את התמיכה ב־Variadic templates שהתווספה ב־gcc-4.3, המאפשרת לבנות פונקציות typesafe עם מספר משתנה של פרמטרים בצורה בטוחה, קצרה ומהירה. התמיכה בהן מקצרת בצורה בסדר גודל את זמן הקומפילציה של תבניות כמו std::function או std::bind.
מבחינתי, יש עוד מספר תכונות שאני מחכה להן:
- תמיכה בביטויי למבדא.
- תמיכה ב־delegating and inheriting constructors שמקצרת בצורה משמעותית את הכתיבה של overloaded constructors.
- תמיכה ב־Concepts שייאפשר לספק פלט שגיאות הרבה יותר ידידותי.
- תמיכה מלאה ב־STL החדש, כולל regular expressions.
אני מקווה שזה לא ייקח הרבה זמן...
