קטגוריה: C

מה שונה ב רובי 2.1

לפני כחודשים שוחרר רובי 2.1, גרסת preview. הוא מכיל כל מיני שינויים, וגם ייצבו כמה תכונות חדשות אשר נכנסו ל2.0, אבל סומנו כ experimental, או במילים אחרות, לא יציבות.
כאשר אני מדבר כאן על רובי, אני מדבר על cRuby/MRI כלומר הגרסה של יוצר רובי, ולא מימושים אחרים כדוגמת jRuby או Rubinius.

להמשיך לקרוא

עוד יום שלישי ה13

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

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

זהירות, הקוד קצר מידי, בייחוד אם משווים לC

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

איך זה שהפלוס דולף ?

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

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

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

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

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

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

הבעיה העיקרית של C ו ++C היא שהן גורמות בשל התחביר, וכן התפיסה שלהן לבעיות אבטחת מידע רבות בעולם המיחשוב. במידה והיו משתמשים באלטרנטיבה שאני מציג,3/4 מהבעיות האלו היו נעלמות, ולמעשה כמות הבאגים שמגיעות בגלל התפיסה והתחביר לא היו מתקיימות בכלל, מה שהיה משאיר סוגים אחרים לגמרי של באגים להתמודד איתם, אשר גם ב C וגם ++C עדיין "נדרשים לתת עליהם את הדין".

אבל כל הטריגר של הפוסט הזה, הוא בכך שלאחרונה רוב תוכנות המבוססות ++C בלינוקס שיוצא לי לעבוד איתם, או זולגות זיכרון כאילו אין מחר, או קורסות לתוך עצמן. זה כבר מרגיש כאילו סוג של פיטצ'ר שמגיע עם השפה, ולא באג. אולי זו הסיבה שחלק מתוכנות ה ++C לאחרונה לא מצליחות לרוץ אצלי. פשוט הקרנל מתלונן על buffer overflow ומיד מחסל את ריצת התוכנה.

טוב אפסיק את הפוסט לפני שיהיה לי עוד segfault

עוד חוזר הדיון, שנזנח כך לשווא …

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

הוא התחיל בדוגמה בכך שבC אפשר לקבוע את רמת הביט של מספר, למשל:

typedef int7b int:7

ואם אתם אוהבי ממים, אז המשפט שהגיע מפי היה בסגנון "bitch please", או בגרסתו העברית – "כלבתא במטותא":

type
  int7b = 0..63;

רגע, אבל למה להתחיל מ0, למה שלא נתחיל מ5 במקום ?

type
  int7b = 5..68;

אתה יכול לעשות את זה ב C ? אה, לא, אוקי. ומה עם זה ?

type
  TMyRec = bitpacked record
    Value : int7b;
  end;

ולהבטיח כי הרשומה בהכרח תקבל דיחסה לפי ביטים ולא לפי גישה אחרת (יש מספר יכולות דיחסה בפסקל לרשומות) ? להמשיך לקרוא

וואוו איזה כלי מגניב

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

אחד הדברים שאני כל הזמן מגלה הוא, עד כמה הם אוהבים את סביבת העבודה שלהם, אבל כל הכלים שיש לסביבת העבודה שלהם, ובכן איך להגיד את זה בצורה לא משתחצנת – משעממים מאוד אנשים שהתרגלו לעבוד עם כלי בורלנד (שנמכרו לחברת אמברקדו). אין באמת משהו מעניין או מסעיר בכלי הפיתוח הללו. עבורי זה משהו די סטנדרטי ב12-15 שנה האחרונות. למעשה ב vim יש יותר כלים מעניינים מאשר אלו המגיעים עם MS Visual Studio.

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

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

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

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

פסקל ברברס

התארחתי בפודקאסט "רברס עם פלטפורמה", ודיברתי מעט על שפת פסקל מונחת עצמים, ובעיקר על FPC.

תודה לאורי ורן על האירוח.

אתם מוזמנים להקשיב , ובעיקר להעריך את העובדה שאני יותר כותב ופחות מדבר 🙂

nvidia widgets

NvWidget_MacOS_386nvidia שחררה לפני מספר שנים sdk להשתמש בAPI שהיא משחררת עבור שימוש ב OpenGL. בעקבות ה sdk, קם פרוייקט אשר יצר רכיבים גרפיים המשתמש ב API של nvidia.

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

לכידת אותות סוררים ביוניקס

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

המטרה היא לא "להעליב" את השפה, או המתכנתים, אלא לפרוק קצת עצבים על השפה הזו והרבה בעיות שיש עם מתכנתים אשר מתעללים בה.

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

הבעיה היא שהתעוד יחסית נורא בנושא כאשר מדובר בתכנות למי שהידע שלו בC אינו הכי חד או קיים בכלל.

למשל אם תכתבו בלינוקס : להמשיך לקרוא

Abbrevia

Abbrevia הוא סוג של toolkit עבור C++ Builder, Delphi, Kylix ו FPC/Lazarus אשר מספק רכיבים וספריות רבות לטיפול בפורמטי קיבוץ שונים כדוגמת ZIP, CAB, LZMA ואחרים.

הtoolkit הוא בעצם סדרת רכיבים בקוד פתוח, אשר חזרה להיות מפותחת אחרי קרוב לעשור, בה היא סתם שכבה בSourceForge. כמו כן, היא כיום עובדת במספר מערכות הפעלה כדוגמת Windows, Linux ו Mac OS-X.

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

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

חברת TurboPower היתה חברה כזו. החברה היתה מאוד מוכרת בעולם בשנות ה80 וה90 בעיקר. היא היתה חברה מאוד קטנה, אבל עם המון פיתוחים אשר שינו את עולם התכנות המקצועי לכל אלו אשר בחרו בדלפי או C++ Builder של בורלנד, ולפני כן גם ב Turbo Pascal ו Turbo C, וכן Borland Pascal ו Borland C.

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

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

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

שליחת הודעות עם d-bus

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

אני ניסיתי לממש מערכת שליחת הודעות למשתמש באמצעות d-bus, אבל זה לא הלך כמו שצריך. לאחר חקירה מאוד ארוכה של הנושא, כדוגמת קריאת תעוד של ה API, ומבט על קוד של אחרים הבנתי כי אין זה פשוט. למשל הקוד של רובי ופיתון עבור d-bus עושה שעטנזים ממש גדולים בשביל לגרום לו לעבוד כמו שצריך. כלומר לא מספיק שלקחו את ה API והתאימו אותו לתפיסת השפה, אלא היו צריכים ללכת עוד הרבה ק"מ בשביל לגרום לזה לעבוד, ולמעשה כמעט כתבו בעצמם את המימוש של הפרוטוקול מ0 רק בשביל שזה יעבוד. אז בהתחלה חשבתי כי אולי הבעיה היא בגלל שהשפות עצמן "בעיתיות" כנראה עם מימוש לקוי של ספריית C. אז התחלתי לחפש מימושים בשפת C, וגיליתי כי גם שם יש המון אנרגיה שנעשית בשביל לגרום לזה לעבוד הרבה מעבר למה שהתעוד הרשמי מבקש.

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

ד"א, לקח לי פחות זמן לממש את הbinding מאשר להבין למה המימוש שלי פשוט לא עובד.