הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
השוואת 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 נותנת מעבר לתחביר שנחשב לקצת יותר קריא? נדמה שלא הרבה.
תגובות
ארתיום, דבר ראשון FPC זה מהדר ולא שפה ! דבר שני, מה זה memory man ? דבר שלישי תכנות פרוצדורלי לא קיים ב פסקל ?! אתה צוחק נכון ? דבר שלישי, ההשוואה הזו לא נכונה. להרבה מקומות שאתה צריך generics ב ++C אפילו בפסקל אתה יכול לעשות את זה בדרך נורמלית יותר, כך שההשוואה של כלים לא נכונה, בגלל שצריך לשאול האם אפשר להגיע לאותו מצב ולא האם אפשרלהגיע עם כלי מסויים בתוך שפה לאותה פעולה.
דבר רביעי ניהול המשאבים של פסקל מחולקת ל2. אתה או מנהל בעצמך או שאתה נותן למהדר לנהל אותו. אני לא יודע אם שמת לב (כנראה שלא) אבל מחרוזת של AnsiString היא מצביע לכל דבר ועניין, אבל אתה לא מנהל אותה. המהדר מנהל בשבילך. בטח בגלל זה לא שמת לב.
דבר חמישי, השלאות שלך ב whatsup הראו שאתה לא מבין את הלך החשיבה של פסקל. אתה כותב לי getter ו setter לשדות, כאשר הדרך הנכונה בפסקל לעשות את זה היא באמצעות property, ובמקרים שלך, אפילו לא היה צריך ליצור פונקציות.
הנה תכונה שאין לך ב C ו ++C אבל יש בפסקל, פיתון, ג'אווה ורובי וזה ניהול namespace אמיתי ! בפסקל כל איזור מכיל namespace משל עצמו שאתה יכול להשתמש בו בשביל להבדיל בין דברים מקומיים למרוחקים וכו'. זוכר את הדוגמה שלך בשאלה ב whatsup שהשתמשתמ ב rect שקיים גם ביחידה classes ? עדיין המהדר היה מסוגל לדעת להתמודד עם זה. ב ++C זה לא כזה פשוט, אבל זה בגלל ששם יש לך רק include שזורק לך את התוכן למיקום שאתה נמצא בו.
בקיצור, אתה כותב כאן הרבה דברים בלי הבנה אמיתית למשמעות של מה שאתה כותב וחבל.
לפני שאתה מדבר על "טעויות" אני אגיד כמה מילים:
מה זה Pascal? זה ייצור ללא הגדרה וללא סטנדרט עדכני. אני יכול לדבר על Delphi שהיא שפה בפני עצמה שבכלל מובססת על Dot.Net היום, גם של FreePascal שהיא גם שפה בפני עצמה שמממשת חלק ממה ש־TP נותן ושל מה ש־Delphi נותן אבל אם אני אדבר על Pascal... העמודה הימנית תהיה שווה לעמודת C... להסביר למה? אני חושב שאתה מבין.
קיצור של memory managment --- ניהול זיכרון.
אתה מתבלבל בין תכנות פרוצדורלי לבין תכנות פונקציונלי שידוע גם בשם Lambda Calculus. אני דיברתי על תכנות פונקציונלי.
ברוב שפות התכנות String מנוהל ע"י מהדר, זה לא מפתיע. השפה היחידה שלא מנהל זיכרון של מחרוזות היא C. אבל עזוב את זה.
אני מדבר על משהו אחד: כיצד אתה מנהל למשל File או Mutex Lock? כיצד אתה מנהל זיכרון של מחלקה שלך.... אתה תמיד חייב לקרוא במפורש להורס.
אני יודע טוב מאוד מה זה property ושהוא קיים ב־FPC (ד"א רציתי שזה היה גם ב־C++, אבל הקוד שהצגתי היה קיצור של קוד אחר לחלוטין שעשה משהו אחר. אני סתם הייתי זקוק לפונקציה כלשהי.
עידו, צר לי, אבל יש לך אחלה namespaces ב־C++, וכל מה ש־include מביא זה שההגדרה שלהם נראית.
עידו, שוב, תקרא את מה שאני כתבתי. אתה מתבלבל בין מושגים שונים.
השוואה מושקעת ומעניינת לקריאה.
דבר אחד שלא כלכך הבנתי - מה זה vendor lock-in בהקשר של פייתון?
תודה.
הכוונה של־Python יש בפועל רק "קומפיילר אחד". אומנם יש Jthon ו־IronPython הם די לא לגמרי תואמים ונועד יותר לתת ל־Python את כל ה־JDK או Net.
כך שבפועל יש רק משערך אחד, כאשר ל־C++ ול־C יש הרבה מהדרים. במיוחד ל־C.
הבנתי אותך. אבל יש אי תאימויות גם בקומפיילרים שונים של C . למרות שיש פתרון אחד נורא פשוט - לכתוב לפי הסטנדרט. זה שיש אי-תאימויות בין ה"קומפיילרים" של פיתון לא מספיק לדעתי כדי לטעון ל-vendor lock-in . הבעיה האמיתית היא מחסור בסטנדרט מוגדר היטב כמו שציינת באחד הסעיפים בטבלה.
עוד שפה שהיה יכול להיות מעניין לראות בטבלה: שפת D http://www.digitalmars.com/d/2.0/comparison.html
בכלל, אני ממליץ מאוד ללמוד על הגישה של D לתיכנות גנרי. גישה מאוד מעניינת לדעתי.
נכון, אבל לא לגמרי. כי יש קומפיילרים שלא תומכים ב־C99 ב־2009... או ליתר דיוק קומפיילר אחד מסוים.
לא לגמרי, כי למשל CPython משתמש ב־reference counting מה שהופך את כל ה"הורסים" למאוד נוחים. לעומת זאת ב־IronPython אי אפשר להסתמך על זה.
בנוסף, הספריות הסטנדרטיות הן מאוד שונות. בקיצור...
זאת בעיה של כל השפות המפותחות ע"י יצרן יחיד.
תכל'ס אני די הרבה זמן מסתכל עליה ורוצה להתעמק בה.
זה נראה כמו משהו בין C#/Java ו־C++ רק עם GC. חוץ מזה אני באמת מעדיף RAII על GC. לא סתם ב־C++ אין finally וגם לא יהיה ;)
http://video.google.com/videoplay?docid=-7073020265668105471
הרצאה על כמה מהפיצרים המעניינים של השפה. ממליץ בחום לצפייה.
לא נעים להגיד אבל קצת מביך לראות אנשים מבוגרים רבים באופן פומבי, אישי ורגשי על שפת־תכנות.
הוסף תגובה:
חובה לאפשר JavaScript כדי להגיב.