ועניין קטן: אני עוברת ל־lazy.nvim (מנהל הפלאגינים; https://lazy.folke.io), לא LazyVim (הסטאפ; https://www.lazyvim.org), אם כי אולי אקח השראות מהסטאפ (עדיין לא יצא לי להסתכל עליו מספיק לעומק).
זה בסך הכול עוד שכבה של אבסטרקציה בצורה של קונפיגורצית ברירת מחדל אנושית, לא?
אני מבסוטה שאני יכולה לקבל דיפולט שעובד מצוין בלי הסתבכויות ואז טוויקים קטנטנים לדברים שאני מעדיפה שיהיו קצת אחרת.
לגמרי. אני פשוט מעדיפה לבנות מאפס כי ההתעסקות עם זה היא כיפית לי.
שיהיה לבריאות.
בעבר הייתי מוכנה להקדיש מלא זמן לקינפוג כדי לקבל משהו שבאמת מתחרה ב־IDE מבחינת חוויית הפיתוח (בעיקר אוטוקומפליט, קפיצה בתוך הקוד, זיהוי הטייפ ודיבאג + קוד אקשנז לקישוט) כי זה היה שווה את זה בשביל הטורבו של קיצורי vim. היה לי פלירטוט קצר עם vscode יחד עם vim mode, אבל זה לא זה.
לייזיווים זה בשבילי השילוב האידיאלי של חוויית vim מעולה עם כל התוספות והפיצ'רים שאני רוצה + כאלה שאפילו לא חשבתי עליהם בלי להשקיע שעות על גבי שעות בלקנפג.
טוב, אז אמרתי שאעיף מבט חטוף על LazyVim כדי לראות איך זה בנוי, במטרה ללמוד מזה רעיונות לבניה של קובץ הקונפיגורציה שלי. Little did I know כמה זה כיף ופשוט ואלגנטי הדבר הזה. הומרתי
בדיוק החוויה שלי. הייתי מאוד סקפטית. חשבתי שזה יהיה דבר מעוך ודעתני שלא מאפשר שינויים והתאמות. נתתי לזה צ'אנס והתאהבתי מייד.
בשלב ראשון הייתי כזה „טוב, נריץ את לנסיון בדוקר¹ שלא יתעסק לי בקבצים” *פרצוף חשדניסט*…
¹ יש כאן פקודה להעתקה: https://www.lazyvim.org/installation
מה שהכי קנה אותי זה ה-discoverability. גם התפריט בהתחלה שמאפשר הרבה דברים מגניבים וגם זה שכל מקש שמתחיל פקודה מורכבת פותח תפריט עם כל תת־הפקודות האפשריות. זה גרסת היוזר־פרנדלי של vim ואני עדיין
הפעם הראשונה שנתקלתי במשהו כזה זה היה עם Doom Emacs: בלי להכיר את המערכת, מצויידת רק בהיכרות עם איך ש־Vim עובד (Doom Emacs תומך ב־evil-mode), הצלחתי תוך רגע להשתמש בזה באופן אפקטיבי, וזה אכן היה מעיף־מוח…
https://github.com/doomemacs/doomemacs
אחד הטאצ׳ים הנחמדים הוא שאם מקישות על המקשים מספיק מהר (כלומר, בקצב של עבודה רגילה כשהרצפים כבר מוכרים ומוטמעים), התפריטים לא עולים — יש להם דיליי קצר, כך שהם יופיעו כשצריך אבל לא יפריעו כשלא. זה יוזר־פרנדלינס אמיתי, שלא מתעקש להיות אובר־פרנדלי כשלא מתאים.
@ruxotves @lulu
כבר לפני זמן רב עברתי ל-https://github.com/nvim-lua/kickstart.nvim שזה לא דיסטרו כמו שזה טמפלייט מאוד מפורט שעליו אפשר לבנות קונפיגורציה אישית. כל שורת קוד שם מוסברת כך שעבורי היה מדובר בחווית למידה מוצלחת מאוד.
אה והרפו של אחד ממפתחי הליבה של neovim
זה מדהים איזו כברת דרך עברה. כשהתחלתי להשתמש ב־Vim כבר היתה תמיכה בפלאגינים, אבל היה צריך להתקין אותם ידנית מ־tarballs, והם זיבלו את אותו המרחב של תתי־ספריות (במקום שכל אחד ישמר עצמאית כמו היום). כדי להסיר, היה צריך לעבור קובץ־קובץ ולמחוק (ולהזהר לא למחוק את הקבצים האחרים). גם עדכונים לא היו פשוטים.
וההגדרות הדיפולטיביות הכילו כל מני דברים מוזרים שדי כולם שינו, ברמה הבסיסית ביותר של איך ש־Vim מתנהג.
זה באמת מרגיש שהמעבר מ־vimscript ל־lua היה שינוי פרדיגמה שאפשר לעבור מעולם של טוויקים בלי סדר לעולם של vim כפלטפורמה או סביבת פיתוח לעורכי טקסט מסדר גבוה יותר.¹ אני זוכרת שההייטרים של vim תמיד אמרו שהיא אף פעם לא תשתווה ל"IDE אמיתי". עכשיו גם מבחינה גרפית וגם מבחינת פיצ'רים אני חושבת שהמצב לגמרי הפוך ואין IDE שמשתווה ל־neovim.
¹ זה מזכיר לי קצת את ההתבגרות של JS משפה איטית וחסרת יכולת שכלואה בקובץ קוד אחד גדול ומבולגן למצב של ימינו עם פריימוורקים ובלקג'ק.
ובעניין של Lua: יש לזה כמובן הרבה יתרונות כלליים מבחינת מהירות, הרחבתיות, קלות כתיבה, סטנדרטיות ועוד, אבל משהו מסויים שקנה אותי באלגנטיות שלו הוא LuaSnip, מערכת snippets שלא רק כתובה ב־Lua, אלא הסניפטים בה נכתבים *ב*־Lua, מה שמאפשר לעשות דברים מאוד מתוחכמים ומטאיים! רמה אחרת לגמרי של גמישות ואבסטרקציה.
https://github.com/L3MON4D3/LuaSnip
ל־TJ DeVries יש סדרה של סרטונים חמודים (פרקים 3–5) על LuaSnip:
https://www.youtube.com/playlist?list=PLep05UYkc6wT87iDtQZ3iafQannL4efEo
מדריך בדגש על מתמטיקה (היי @yaarur!
https://ejmastnak.com/tutorials/vim-latex/luasnip/
#לואה
בעקבות [הדף הזה](https://castel.dev/post/lecture-notes-1) התחלתי להשתמש בזמנו ב־UltiSnips. זה שינה לגמרי את האופן שבו אני כותבת, וזאת מערכת נהדרת, אבל היא גם איטית (Vim script) ומבוגגת¹ וגם כל מה שמעבר להחלפות פשוטות ותבניות פשוטות מרגיש כמו second-class citizen והאקי. עם LuaSnip גם הדברים הפשוטים וגם הדברים הסופר־מורכבים (כמו התנהגות שונה לפי ניתוח של Tree-sitter!!
¹ לפחות אצלי היו באגים בתסריטים מסויימים; לא בטוחה על מי האשמה.
טוב, צפיתי בסרטונים של TJ DeVries ועף לי המוח לתקרה! איפה זה היה כל החיים שלי?! כל כך מתסכל שזה לא משהו שקל להסביר מה הוא עושה ב־tldr.
בהערת אגב, ה־tour de force של התבנית לטיפול בשגיאות בגו מדגים בדיוק למה אני לא יכולה לסבול את גו כשפת תכנות. לא רק שיש בה null pointers בימינו אלא גם טיפול בשגיאות כל כך לא אלגנטי שקוד רגיל נראה כמו הצרות שלי ביום רע. כלומר: זה פתרון אלגנטי ומרהיב לבעיה שלא היתה צריכה להתקיים מלכתחילה בשפת תכנות אנושית.
בראסט, כמובן, זה לא היה קורה.
וכדי להסביר את הנקודה, הפתרון לשתי הבעיות: null pointers ושגיאות כ־return value הוא data enums הידועים גם בשם discriminated unions. במקום להחזיר ערכים דיפולטיבים (ועוד null, לא עלינו, שמחביא את הטייפ שלו ומאפשר בקלות להתעלם מקיומו), הרבה יותר הגיוני להחזיר תת־טייפ (או מקרה של enum או union) שונה במקרה השמח ובמקרה העצוב וככה לא צריך למלא משבצות מיותרות בערכים דיפולטיבים.
שפות בלי sum types / data enums / discriminated unions ניגשו לבעיית ה־null בעזרת מערכת הטייפים, ככה שטייפ של דבר שיכול להיות null מסומן כ־nullable בניגוד לכזה שחייב להכיל ערך.
אחרי זה, הקומפיילר אחראי לא לאפשר לגשת לטייפ שהוא nullable בלי לעשות בדיקת null. אחרי בדיקת null, הטייפ משתנה ללא־nullable ואז אפשר לגשת אליו.
let thing: Nullable<Thing> = get_thing();
if (thing != null) {
// thing is now of type Thing
} else {
// thing is now of type Null
}
זה עדיין מחייב לעשות בדיקת null כמו בגו, אבל הקומפיילר מחייב אותה וגם בהרבה מהשפות האלה יש syntactic sugar כדי להקל על הטיפול בזה. למשל בקוטלין יש את ה־elvis operator.
הנה תיאור של העניין בקוטלין:
https://kotlinlang.org/docs/null-safety.html
@lulu @ruxotves @yaarur
אין לי ניסיון בראסט, אבל ממה ששמעתי הטיפול בשגיאות הוא error as value. אם כך זה מהותית כמו בגו, רק שבראסט יש אופרטור סימן שאלה, בעוד בגו צריך לכתוב ביטוי. זה שאין optional יותר בעייתי בגו בעיניי (אבל עדיין נהנה מהשפה).
גם ב-C יש error as value, אבל בגירסה הכי גרועה אבר, כי שגיאה זה לא tagged union, אלא int שצריך לחפש איפשהו מה זה אומר.
אני כרגע נהנה מאוד לכתוב -zig שזה כמו C אבל מכיל כל מה שתצפו משפה מודרנית, כולל טיפול בשגיאות ו-optional, וcompile time code.
כן, אני מסכימה, אבל כוח העל של ראסט הוא sum types ככה שה־error as value הוא טייפ נפרד מהטייפ של הערך שהוא לא שגיאה. זה אומר שכשמחזירים ערך שגיאה לא צריך לאפס (או לדחוף ערכי ברירת מחדל) לטייפ של הלא־שגיאה כמו בגו - שזה מה שהפתרון בLuaSnip עושה.
זאת ועוד, בראסט יש אופרטור סימן שאלה שמאפשר לחלץ את הערך אם אין שגיאה ואם יש שגיאה להחזיר אותה ישירות.
זאת ועוד, יש בראסט פונקציות־עזר שמאפשרות לטפל ב־sum types כמו
Option<T>
או
Result<T, E>
כדי לקצר את הבדיקות הידניות.
ולעניין zig, זאת בהחלט שפה מגניבה ומודרנית ולהבנתי היא כמו ראסט מבחינת העניינים שדיברנו עליהם.
מה שחסר לה בהשוואה לראסט זה memory safety ו־thread safety בעזרת מערכת הטייפים ובדיקות של הקומפיילר על בסיס מודל ה־ownership and borrowing. הטיעון לטובת zig זה שבראסט יותר קשה לעבוד מהר באיטרציות קצרות (כי הקומפיילר מציק עם הודעות שגיאה) וזאת צורת הפיתוח המקובלת בעולם הגיימינג.
@lulu @ruxotves @yaarur
ב-zig זה בהחלט intended שלא צריך להתעסק עם ה-borrow checker. זה מפשט את איכות החיים . מצד שני זה לא שלגמרי אין memory saftey. ב-zig יש optional type שהקומפיילר מכיר כ- type ייחודי, בדוחה לראסט. אותו הדבר לגבי שגיאות.
בהקשר של ספריות C יש בזיג opaque type, שבמקרים שאי אפשר להיות בטוח באימפלמנטציה של הספריה (למשל סטראקטים עם bit fields הידועים לשמצה) אפשר להכריז על opaque שהקומפיילר מזהה ומגביל בשימוש כך אפשר לשמור על saftey.
אני גם התרשמתי שזיג זאת שפה חמודה.
מה שאני מתכוונת ב־memory safety זה לא התממשקות עם טייפים משפות תכנות אחרות או הימנעות מ־null pointer exception. אני מתכוונת ספציפית לדברים כמו: שימוש בזכרון ששוחרר (בכתיבה או קריאה), פוינטרים למקומות לא נכונים (כי הדאטה הוזז) והזדמנויות לשחרור זכרון כפול או אלוקציה כפולה. ובהקשר של הפתרון של ראסט, השאלה היא איך למנוע את כל הדברים האלה בלי מחיר בזמן הריצה.
כן. אני גם מאמינה בתועלת שבזה לרוב צורות הפיתוח שרלוונטיות בשבילי.
אני יודעת שיש ביקורת מצד עולם הגיימינג שנראית לי (וגם לכמה דוברותים אחרותים מקהילת הראסט) סבירה והגיונית. כשמפתחים משחק, הרבה פעמים המודל משתנה כל הזמן בין איטרציות כי לוקח זמן עד שמבינים איזה משחק בכלל מנסים לבנות ואיך למדל אותו. בראסט כל שינוי כזה כרוך בריפאקטור הכללי (על משקל: תיקון הכללי) וייסורי קומפיילר. זה באמת נכון שראסט לא כל כך בשימוש לפיתוח משחקים.