אולי Functional Programming נשמע כמו שיעור סטודיו בחדר כושר, אבל למרות שהשם שלו נשמע מיינסטרימי, יש פילוסופיה שלמה ומעניינת מאחוריה.
המוטיב המרכזי שחוזר: פונקציות. לפשט את הכל לפונצקיות, ולהתייחס אל פונקציות בעדינות וחוכמה. כל קטע קוד שקיים במערכת, צריך להיות עטוף כפונקציה המבצעת פעולה אחת פשוטה, תוך קבלת קלט, ופליטת פלט כלשהו.
הרעיון מאחורי המוטיב לקוח מהגישה המתמטית: הפונקציה מבצעת פעולה אחת, אתה יודע מה היא, ומה תהיה התוצאה בהתאם לקלט. ובקוד, זה מתבטא בכך שאתה לא צריך “לדבאג” את הפונקציה ולהבין מה לא בסדר איתה, אלא אמור לקחת בחשבון שהיא עובדת כמו שצריך (אם נכתב כמו שצריך), וגם ברורה בדיוק מה היא עושה, כך שאתה בכלל לא צריך להתחיל להיכנס לכל פונקציה בקוד. כל הבעיות שיכולות “לצוץ” צריכות להיות קשורות בשרשור והלוגיה של הפונקציות, ולא בפונקציות עצמן.
בנוסף, בתכנות פונקציונאלי (שאתייחס כ-FP) כל האובייקטים הם immutable, כלומר ברגע שמייצרים אותם, אסור לשנות אותם. אם אתה רוצה לערוך אותם, תצטרך להחזיר עם פונקציה אובייקט חדש עם הערכים החדשים. לחידוד, להעביר כקלט את האובייקט לפונקציה ולערוך את האובייקט בתוך הפונקציה עצמה לא מתקבל בחשבון.
וכמובן, שאין יותר forloop, במיוחד fori (בגלל שהוא מבצע שינוי סטייט ל-i!), ובכדי לבצע איטרציה כלשהיא, משתמשים ברקורסיה (בכל זאת, אני ראיתי מספיק מתכנתיי FP שעדיין משתמשים בforeach, ולא נראה שהעולם קרס להם).
לסיום, ל-FP יש מה לומר גם על error handling & null. מכיוון שפונקציות ב-FP הן כמו אלגברה, אין לך בדיוק ערך של NULL. השיטה המקובלת היא לעטוף את הערך המוחזר באובייקט כלשהוא, ולבדוק אם יש בו ערך (או לקרוא לפונקציה מתאימה). בשפות שמשרישות פילוסופיה FPית (כמו קוטלין וסקאלה) זה קצת יותר מחומם מזה.
כדי למנוע אקספשיינס, ב-Go הפכו כל שגיאה לערך בפני עצמו. אתה כבר לא מקריס את האפליקציה כשנוצרת לך השגיאה, אלא מחזיר אותה בפונקציה כערך בפני עצמו (בדר"כ כסוג של Tupel) ונותן לקורא הפונקציה להסתבך עם עצמו. האם זה יעיל? אולי, אבל דורש המון שכפול קוד.
בתמונה: קטע מאימון פונקציונאלי שרשורי, וקצת קריא יותר. החדי קרן מבינינו יבחינו שאפשר לקצרר את השורה עוד יותר.