מהי שפת התכנות של ג'יני?

בטוח מאובטח. לא כמו ה "monolithic blobs" of Bitcoin and other cryptocurrencies, Gini's systems are designed to be מאובטחת, which means it will be possible to employ mathematical analysis of Gini's systems to provide quantifiable assurances that the software source code can perform as expected within specific statistical thresholds of security and reliability. This is possible primarily because Gini's systems and architecture are created with the שפת התכנות Haskell, אשר יש יתרונות טכניים ייחודיים רבים. זו הסיבה שהסקל משמשת את נאס"א, לוקהיד מרטין, בואינג וחברות תעופה וחלל רבות אחרות, שצריכות לבנות מערכות בטוחות ומאובטחות עבור מטוסים, לוויינים, מעבורות חלל ומערכות קריטיות אחרות שיש לבצע ברמה יוצאת דופן של בטיחות, אבטחה ואמינות.

אמינות גבוהה קוד ג 'יני. Since the core Gini components (Gini Settlement Layer and Gini Computation Layer) are produced with Haskell, which is classified as a "פונקציונלי programming language," Gini's software source code is up to 80% more time- and cost-efficient than it would be if we used other הכרחי (aka, פרוהליך  או מונחה עצמים) שפות כמו C + +, C #, Java, וברוב השפות האחרות. Haskell מפחיתה באופן דרמטי את מספר באגים חורים אבטחה במהלך מחזור החיים של התוכנה. Haskell גם התוצאות הרבה יותר אלגנטי קוד לתחזוקה, אשר תוצאות משמעותי יותר אמין וחסכוני מערכות. (הנה כמה סקירות טכנית טובה מ מיקרוסופט וה קהילת קוורה על היתרונות של שפות תכנות פונקציונליות).

עוד כמה נקודות טכניות על Haskell:

Haskell is a "functional programming language," כלומר כמעט הכל Haskell מבוסס על הגדרות פונקציה. זה עושה קוד מאורגן יותר לקריאה מאלצת את המקודד לחשוב על פתרון בעיות בצורה עמוקה יותר ואינטואיטיבי, ולא לתת למחשב סדרה ארוכה של פקודות מייגעות, decontextualized לעשות את אותה התנהגות. זה גם אומר כי קידוד ב Haskell מתמקדת בתיאור אילו נתונים / פונקציות הם הרבה יותר ממה שהם צריכים לעשות. יש לכך השלכות מעניינות ומשמעותיות רבות על כל היבט של תהליך קידוד.

Everything in Haskell is "immutable," כלומר: לאחר קביעת ערך עבור משתנה נתון, קבוע או פונקציה, ערך זה מוגדר לנצח (או כל עוד התוכנית פועלת). Immutability הוא מה מונע באגים רבים כי זה מונע משתנים ו פונקציות המשתנות בחלק מהתחום המקומי מ יצירת תופעות לוואי בלתי צפויות / בלתי צפויות בעולם בפונקציות אחרות התלויות באותו משתנה / פונקציה לאורך כל התוכנית.

In fact, Haskell technically doesn't have "variables"; it has "constants" (values) and "functions" (which are also treated as values) that never change. The only way to update a constant/function in Haskell is to define a new constant/function. However, the scope of a constant matters. For example, a constant declared at the global level can be הוכרז מחדש כערך אחר בתוך פונקציה אחרת שמטפלת בפעולות קלט / פלט, אך ערך חדש זה רק קיים בתוך היקף מקומי של פונקציית I / O. הוא אינו משנה את הערך של הקבוע בהיקף הגלובלי או בתוך ההיקף המקומי של כל פונקציה אחרת.

Immutability עושה קוד haskell refactoring ממש מהיר ויעיל because there's no possibility for unexpected gotchas (i.e., side-effects and state changes) that might cause a program to crash or create unexpected security vulnerabilities. In Haskell, the value of functions, variables, and constants can't be changed during run-time after they've already been declared, which simplifies source code analysis during the refactoring process. This eliminates one of the most tedious parts of refactoring and optimizing code: function performance profiling. Thus, it's much easier to maintain, update, and continuously improve all our Haskell-based Gini systems over time.

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

In Haskell, we say "functions are first-class citizens." משמעות הדבר היא שניתן להעביר פונקציות כפרמטר / ארגומנט לפונקציות אחרות בדיוק כמו כל משתנה או ערך אחרים. זה פותח כמות עצומה של אפשרויות יצירתיות כדי לכתוב נקי, יעיל, אמין, קוד אלגנטי, אשר שפות שאינן פונקציונליות לא יכול לשכפל.

היכרות & השגיאה זמן איתור. Haskell נחשב נרחב שיש את מערכת חכמה ביותר של כל שפת תכנות. משמעות הדבר היא סוגי נתונים (למשל, מחרוזות, מספרים שלמים, בוליאנים, רשימות, ועוד רבים אחרים) באופן אוטומטי ו כראוי detected by Haskell's type system and intelligently inferred from how the functions interact with the values that are passed between functions. For this reason, many computer scientists say, "In Haskell, if it compiles, it's correct." This may seem like a boring, arcane concept, but it's actually one of the most significant reasons why programs built with Haskell are so reliable and secure.

In fact, typeclass errors and associated bugs frequently cause software programs to crash when they're written in other languages because the compilers and interpreters for those other languages often allow disparate data types to interact with one another, which can cause unexpected results. For example, if a function passes a string type (e.g., "four") to another function, but the receiving function is expecting an integer type (e.g., 4), the receiving function will choke because it doesn't know what "four" actually means. This type of scenario causes many programs to crash, but Haskell completely prevents these crashes by catching type errors or intelligently inferring typeclass membership for a given value before a program is even deployed to a live environment.

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

Code abstraction is a byproduct of Haskell's extremely intelligent compiler. המהדר Haskell intuits פעולות רבות גורמים הקשריים כי לצמצם את הקוד הכולל הנדרש כדי לייצר התנהגות מסוימת התוכנית על ידי עד 70% (או אפילו יותר אם הרכב פונקציה is used). This is one of the primary reasons why the Haskell-based Web server ("Warp") can be written בתוך פחות מ -1,000 שורות קוד בזמן ש שרת האינטרנט Apache דורש כ 1.5 מיליון שורות קוד. ו עיוות הוא מעל 100x מהר יותר מאשר אפאצ 'י ופחות הרבה פחות חשופים באגים רבים פריצות אבטחה. (כמובן, כל המדדים תלויים איך כל מערכת מוגדרת, אבל באופן כללי, Warp's per-CPU HTTP request processing is at least two orders of magnitude faster than a similarly powered server running Apache without any load-balancing and caching techniques.)

Haskell has no "for" or "while" loops or "variables" במובן השכלתי, אבל יש לה קבועים ותכונות חזקות מאוד של רקורסיה ותבניות. אלה להחליף את הצורך עבור / לולאות בזמן משתנים משתנים. למעשה, recursion והתאמה דפוסים הם כלים יעילים הרבה יותר כדי לבצע את אותן משימות, ולכן שפת התכנות Haskell אינו כולל עבור / בזמן לולאות.

Haskell הוא עצלן. Being lazy is not always a virtue, but in this case, it means that Haskell always consumes the least amount of resources (CPU, memory, and thus, electricity) possible. Specifically, Haskell doesn't force a computer to execute more CPU cycles or consume more memory than is needed at the moment of each function's execution. For example, in Haskell we can define an infinite list of data objects at any time, but a Haskell program will not traverse the entire list because that would quickly consume all system resources and cause it to crash. Instead, a Haskell function will only traverse an infinite list until it finds the value it's looking for based on the efficient pattern-matching functions that Haskell provides. (See note 4 for a special exception to Haskell's laziness.)

לסיכום: Haskell's approach to system resource management and its intelligent typeclass system alone eliminate many (50-70%) of all the bugs and security vulnerabilities that typically plague code written in other programming languages. Haskell's virtuous lazy processing prevents many stack and heap buffer overflows and corresponding system crashes caused by unintended infinite loops, which are often caused by poorly designed code in non-functional programming languages. Haskell's succinct syntax and well-organized functional design philosophy enforce good coding habits, which also eliminates many bugs.

Haskell provides many other benefits, but the benefits listed above are several of the most significant reasons why we chose to build Gini's systems with Haskell. To learn a lot more about Haskell, visit the Haskell שפה.

---

הערות:

1. Some of Gini's early prototypes and test systems are built with Java, C++, and Python, but those are just for our R&D and proof-of-concept systems. The 1.0+ versions of all Gini systems will always be built with Haskell (for PC-based systems) and standard Web-based languages (e.g., browser-agnostic Javascript, HTML, and CSS delivered on the Haskell-based Yesod/Warp Web framework) for all Web-based Gini systems. Mobile apps for Gini are built in Haskell and cross-compiled into each mobile platform's native language (e.g., Objective-C for iOS and Java for Android).

2. Some open source software libraries that are integrated into Gini's systems (including certain well-known cryptography packages like the בלייק פונקציה hashing ואת ארגון 2 הפונקציה derivation מפתח) נכתבים ב- C, C + + ו- Java ולעתים אנחנו צריכים לבנות ממשקים בינם לבין רכיבי Haskell שלנו. עם זאת, אנו שואפים להשתמש Haskell עבור כמה מרכיבים ג 'יני ככל האפשר; ועם הזמן, אנחנו נחליף ספריות קוד פתוח ללא Haskell עם ספריות קוד פתוח מבוססות Haskell ו / או רכיבים מבוססי Haskell שלנו בכל פעם שאנו מאמינים שזה יגרום המערכות שלנו מאובטחת יותר ואמינה.

3. כל תוכנת ג 'יני ישוחרר לקהילת קוד פתוח לאחר ההשקה הרשמית ג'יני בלוקגריד ו ג 'יני עבור הציבור הרחב.

4. יש שני חריגים לתכונה עצלה ב Haskell: Strict Bytestrings ו Lazy Bytestrings. Strict Bytestrings מייצגים נתונים כמו נתחי נתונים של 8 סיביות (1-בתים) הם לא עצלנים, but they're used in special cases where large data files must be processed more efficiently than the typical lazy processing. In contrast, Lazy Bytestrings represent data as 64K-byte data chunks, the first of which is processed immediately like Strict Bytestrings, but all subsequent 64K-byte data chunks within a given file (or data stream) are processed lazily, i.e., processing is deferred until the data is actually needed for a given function.

---