השוואת FPC ושפות אחרות

ב־18.5.2009, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים; ‏8 תגובות

נתחיל מהטבלה שמשוואה מספר שפות תכנות פופולריות: Python, Java, C, C++‎ ו־FPC.‏ כאשר אני מתמקד במספר רבדים: תכונות שפה מרכזיות, סגנונות פיתוח ותכנות אפשריים, ספריות וספקים.

השוואה לפי תכונות:

FeaturePythonJavaCC++FreePascal
Core:
Memory man.AutomaticAutomaticManualSemi-AutomaticManual
Resources man.Automatic1ManualManualSemi-AutomaticManual
InheritenceMultipleSinlgeNoMultipleSingle
PolymorphizmDuckDynamicNoDynamic+StaticDynamic
ReflectionYesYesNoNoNo
Language Features
Generic ProgrammingIrrelevantLimitedNoTuring CompleteLimited
Generic methodsIrrelevantYesNoYesNo
Requires interfeceIrrelevantYes-NoNo
Functional ProgrammingYesVery LimitedNoC++03 Limited
C++0x Full
None
Libraries:
Standard:RichRichPoorLimitedRich
  conteinersYesYesNoYesYes
  threadingYesYesNoNoYes FCL
  GUIYesYesNoNoYes LCL
3rd party libs.:RichRichRichRichPoor
Other:
  StandardsNoneYesYesYesOutdated
  Implementations:CPython, Jthon, IronPythonGNU, Sun, IBMLotsMany: GNU, MS, HP, Sun, Intel...Single
  Defacto-VendorYes: CPythonYes: SunNoneNoneFPC
  PerformancePoorMediumHighHighHigh

הערות:

  1. רק ב־CPython.

סיכום:

  1. Python: נותנת לעבוד עם כל סגנונות פיתוח אפשריים, קל לפיתוח וניהול משאבים, אבל סובל משתי בעיות עיקריות: ביצועים ו־vendor lock in.‏
  2. Java: שפה יחסית מגבילה מבחינת הגישה שלה, אבל בטוחה לפיתוח ותכנות בזכות: GC, ספריה סטנדרטית מאוד עשירה פשטות השפה.
  3. C: שפה שכמטע ולא מספקת כלים "מודרניים"... כבודה במקומה מונח, ועדיין יש לה המון יישומים במיוחד בתחום embedded, או כל תחום אחר בו צריך לרדת לרמת תכנות נמוכה ולשמור על קומפקטיות וקריאות של הקוד.
  4. C++‎: שפה מאוד עשירה, הרכיבים המודרניים היחידים שחסרים לה זה: העדר Reflection, העדר GC מלא (אם כי ב־C++‎‏ RAII מחליף אותו בהצלחה) ואולי צורך בספריות צד ג'. כמובן עם הכוח בא גם החיסרון: שפה מסובכת שלוקח זמן ללמוד אותה לעומק ולהבין את הרבדים השונים שלה.
  5. עכשיו הגיע תורה של FPC:‏ היא נמצאת איפשהו בין C לבין Java:
    • מצד אחד, אין לה GC ומצד שני אין לה גם RAII שיש ב־C++‎, ניהול המשאבים שם ידני לחלוטין ממש כמו ב־C.
    • יכולות הירושה מוגבלות לירושה בסגנון C#/Java.
    • תמיכה ב־Generics מוגבלת, אין תכנות פונקציונלי (במובן lambda calculus) וגם אין Reflection.
    • ספריה סטנדרטית די עשירה (אם לוקחים גם FCL ו־LCL), אבל העדר ספריות צד ג' כואב, הרבה יותר

נשאלת השאלה: מהו הערך המוסף ש־FreePascal נותנת מעבר לתחביר שנחשב לקצת יותר קריא? נדמה שלא הרבה.

תגובות

ik_5, ב־18.5.2009, 12:25

ארתיום, דבר ראשון FPC זה מהדר ולא שפה ! דבר שני, מה זה memory man ? דבר שלישי תכנות פרוצדורלי לא קיים ב פסקל ?! אתה צוחק נכון ? דבר שלישי, ההשוואה הזו לא נכונה. להרבה מקומות שאתה צריך generics ב ++C אפילו בפסקל אתה יכול לעשות את זה בדרך נורמלית יותר, כך שההשוואה של כלים לא נכונה, בגלל שצריך לשאול האם אפשר להגיע לאותו מצב ולא האם אפשרלהגיע עם כלי מסויים בתוך שפה לאותה פעולה.

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

דבר חמישי, השלאות שלך ב whatsup הראו שאתה לא מבין את הלך החשיבה של פסקל. אתה כותב לי getter ו setter לשדות, כאשר הדרך הנכונה בפסקל לעשות את זה היא באמצעות property, ובמקרים שלך, אפילו לא היה צריך ליצור פונקציות.

הנה תכונה שאין לך ב C ו ++C אבל יש בפסקל, פיתון, ג'אווה ורובי וזה ניהול namespace אמיתי ! בפסקל כל איזור מכיל namespace משל עצמו שאתה יכול להשתמש בו בשביל להבדיל בין דברים מקומיים למרוחקים וכו'. זוכר את הדוגמה שלך בשאלה ב whatsup שהשתמשתמ ב rect שקיים גם ביחידה classes ? עדיין המהדר היה מסוגל לדעת להתמודד עם זה. ב ++C זה לא כזה פשוט, אבל זה בגלל ששם יש לך רק include שזורק לך את התוכן למיקום שאתה נמצא בו.

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

ארתיום, ב־18.5.2009, 12:55

לפני שאתה מדבר על "טעויות" אני אגיד כמה מילים:

דבר ראשון FPC זה מהדר ולא שפה

מה זה Pascal? זה ייצור ללא הגדרה וללא סטנדרט עדכני. אני יכול לדבר על Delphi שהיא שפה בפני עצמה שבכלל מובססת על Dot.Net היום, גם של FreePascal שהיא גם שפה בפני עצמה שמממשת חלק ממה ש־TP נותן ושל מה ש־Delphi נותן אבל אם אני אדבר על Pascal... העמודה הימנית תהיה שווה לעמודת C... להסביר למה? אני חושב שאתה מבין.

דבר שני, מה זה memory man?

קיצור של memory managment --- ניהול זיכרון.

דבר שלישי תכנות פרוצדורלי לא קיים ב פסקל ?!

אתה מתבלבל בין תכנות פרוצדורלי לבין תכנות פונקציונלי שידוע גם בשם Lambda Calculus. אני דיברתי על תכנות פונקציונלי.

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

ברוב שפות התכנות String מנוהל ע"י מהדר, זה לא מפתיע. השפה היחידה שלא מנהל זיכרון של מחרוזות היא C. אבל עזוב את זה.

אני מדבר על משהו אחד: כיצד אתה מנהל למשל File או Mutex Lock? כיצד אתה מנהל זיכרון של מחלקה שלך.... אתה תמיד חייב לקרוא במפורש להורס.

אתה כותב לי getter ו setter לשדות

אני יודע טוב מאוד מה זה property ושהוא קיים ב־FPC (ד"א רציתי שזה היה גם ב־C++‎, אבל הקוד שהצגתי היה קיצור של קוד אחר לחלוטין שעשה משהו אחר. אני סתם הייתי זקוק לפונקציה כלשהי.

ב ++C זה לא כזה פשוט, אבל זה בגלל ששם יש לך רק include שזורק לך את התוכן למיקום שאתה נמצא בו.

עידו, צר לי, אבל יש לך אחלה namespaces ב־C++‎, וכל מה ש־include מביא זה שההגדרה שלהם נראית.

עידו, שוב, תקרא את מה שאני כתבתי. אתה מתבלבל בין מושגים שונים.

shlomil, ב־18.5.2009, 13:27

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

דבר אחד שלא כלכך הבנתי - מה זה vendor lock-in בהקשר של פייתון?

תודה.

ארתיום, ב־18.5.2009, 13:31

השוואה מושקעת ומעניינת לקריאה. דבר אחד שלא כלכך הבנתי - מה זה vendor lock-in בהקשר של פייתון? תודה.

הכוונה של־Python יש בפועל רק "קומפיילר אחד". אומנם יש Jthon ו־IronPython הם די לא לגמרי תואמים ונועד יותר לתת ל־Python את כל ה־JDK או Net.

כך שבפועל יש רק משערך אחד, כאשר ל־C++‎ ול־C יש הרבה מהדרים. במיוחד ל־C.

shlomil, ב־18.5.2009, 13:52

הבנתי אותך. אבל יש אי תאימויות גם בקומפיילרים שונים של C . למרות שיש פתרון אחד נורא פשוט - לכתוב לפי הסטנדרט. זה שיש אי-תאימויות בין ה"קומפיילרים" של פיתון לא מספיק לדעתי כדי לטעון ל-vendor lock-in . הבעיה האמיתית היא מחסור בסטנדרט מוגדר היטב כמו שציינת באחד הסעיפים בטבלה.

עוד שפה שהיה יכול להיות מעניין לראות בטבלה: שפת D http://www.digitalmars.com/d/2.0/comparison.html

בכלל, אני ממליץ מאוד ללמוד על הגישה של D לתיכנות גנרי. גישה מאוד מעניינת לדעתי.

ארתיום, ב־18.5.2009, 14:12

למרות שיש פתרון אחד נורא פשוט - לכתוב לפי הסטנדרט.

נכון, אבל לא לגמרי. כי יש קומפיילרים שלא תומכים ב־C99 ב־2009... או ליתר דיוק קומפיילר אחד מסוים.

זה שיש אי-תאימויות בין ה"קומפיילרים" של פיתון לא מספיק לדעתי כדי לטעון ל-vendor lock-in

לא לגמרי, כי למשל CPython משתמש ב־reference counting מה שהופך את כל ה"הורסים" למאוד נוחים. לעומת זאת ב־IronPython אי אפשר להסתמך על זה.

בנוסף, הספריות הסטנדרטיות הן מאוד שונות. בקיצור...

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

זאת בעיה של כל השפות המפותחות ע"י יצרן יחיד.

עוד שפה שהיה יכול להיות מעניין לראות בטבלה: שפת D http://www.digitalmars.com/d/2.0/comparison.html

בכלל, אני ממליץ מאוד ללמוד על הגישה של D לתיכנות גנרי. גישה מאוד מעניינת לדעתי.

תכל'ס אני די הרבה זמן מסתכל עליה ורוצה להתעמק בה.

זה נראה כמו משהו בין C#/Java ו־C++‎ רק עם GC. חוץ מזה אני באמת מעדיף RAII על GC. לא סתם ב־C++‎ אין finally וגם לא יהיה ;)

shlomil, ב־18.5.2009, 14:26

http://video.google.com/videoplay?docid=-7073020265668105471

הרצאה על כמה מהפיצרים המעניינים של השפה. ממליץ בחום לצפייה.

אריאל, ב־19.5.2009, 10:53

לא נעים להגיד אבל קצת מביך לראות אנשים מבוגרים רבים באופן פומבי, אישי ורגשי על שפת־תכנות.

הוסף תגובה:

 
 כתובת דוא"ל לא תוצג
 

ניתן לכתוב תגובות עם שימוש בתחביר Markdown.

חובה לאפשר JavaScript כדי להגיב.

דפים

נושאים