Qual linguagem de programação é construída com o Gini?

Provavelmente seguro. Ao contrário do "monolithic blobs" of Bitcoin and other cryptocurrencies, Gini's systems are designed to be Provavelmente seguro, 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 Linguagem de programação Haskell, que tem muitos benefícios técnicos exclusivos. É por isso que a Haskell é usada pela NASA, Lockheed Martin, Boeing e muitas outras empresas aeroespaciais e de defesa que devem construir sistemas seguros para aviões, satélites, ônibus espaciais e outros sistemas de missão crítica que devem funcionar em um nível excepcional de segurança, segurança e confiabilidade.

Código Gini de alta confiabilidade. Since the core Gini components (Gini Settlement Layer and Gini Computation Layer) are produced with Haskell, which is classified as a "funcional programming language," Gini's software source code is up to 80% more time- and cost-efficient than it would be if we used other imperativo (aka processual  ou Orientado a Objeto) linguagens como C ++, C #, Java e a maioria das outras linguagens. Haskell reduz drasticamente o número de bugs e falhas de segurança ao longo do ciclo de vida de um programa de software. O Haskell também resulta em um código muito mais elegante e de fácil manutenção, o que resulta em sistemas substancialmente mais confiáveis ​​e econômicos. (Aqui estão algumas boas visões técnicas de Microsoft e a Quora Community sobre os benefícios das linguagens de programação funcionais.)

Mais alguns pontos técnicos sobre Haskell:

Haskell is a "functional programming language," o que significa que praticamente tudo em Haskell é baseado em definições de função. Isso torna o código mais organizado e legível e força o codificador a pensar em resolver os problemas de uma maneira mais profunda e intuitiva, em vez de fornecer ao computador uma longa série de comandos entediantes e descontextualizados para realizar o mesmo comportamento. Isso também significa que a codificação em Haskell é focada na descrição de quais dados / funções está muito mais do que deveriam Faz. Isso tem muitas implicações interessantes e significativas para todos os aspectos do processo de codificação.

Everything in Haskell is "immutable," o que significa: Quando um valor é definido para uma dada variável, constante ou função, esse valor é definido para sempre (ou enquanto o programa estiver sendo executado). Imutabilidade é o que impede muitos erros, pois evita variáveis e funções que são alteradas em algum escopo local da criação de efeitos colaterais inesperados / inesperados em outras funções que dependem da mesma variável / função em todo o programa.

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 declarado novamente como um valor diferente dentro de outra função que manipula operações de E / S, mas esse novo valor só existe dentro do alcance local dessa função de E / S. Não altera o valor da constante no escopo global ou dentro do escopo local de qualquer outra função.

A imutabilidade torna a refatoração do código Haskell realmente rápida e eficiente 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 tem transparência referencial, o que significa que as funções nas expressões Haskell e seus valores de saída podem ser usados de maneira intercambiável sem alterar o comportamento do programa. Isso está relacionado à imutabilidade, mas a transparência referencial refere-se ao fato de que as funções sempre produzirão o mesmo resultado dado a mesma entrada, que é uma propriedade muito útil quando se trata de depuração, auditorias de segurança, paralelização, simultaneidade e otimização de código. É por isso que o Haskell normalmente tem desempenho excepcionalmente bom em aplicativos de rede concorrentes de alto volume e alto rendimento. Em contraste, funções em linguagens imperativas geralmente dependem do estado de outras funções e variáveis, que podem mudar a qualquer momento, dependendo do estado de outros componentes de um programa. Isso cria muitos riscos e incertezas que tornam muito mais difícil garantir a segurança e a integridade dos programas escritos em linguagens não funcionais.

In Haskell, we say "functions are first-class citizens." Isto significa que as funções podem ser passadas como um parâmetro / argumento para outras funções assim como qualquer outra variável ou valor. Isso abre uma grande quantidade de possibilidades criativas para escrever código limpo, eficiente, confiável e elegante, que as linguagens não funcionais não podem replicar.

Inferência de Typeclass Inteligente e Detecção de Erro em Tempo de Compilação. Haskell é amplamente considerado como tendo o sistema typeclass mais inteligente de qualquer linguagem de programação. Isso significa que tipos de dados (por exemplo, strings, inteiros, booleanos, listas e muitos outros) são automaticamente e corretamente 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.

Recursão é usada com freqüência. Isso cria funções mais poderosas e eficientes com menos código, mas funções recursivas aninhadas podem ser confusas para iniciantes do Haskell porque o código tende a ser mais abstrato do que o código em linguagens imperativas.

Code abstraction is a byproduct of Haskell's extremely intelligent compiler. O compilador Haskell intui muitas ações e fatores contextuais que reduzem o código total necessário para produzir um determinado comportamento de programa em até 70% (ou ainda mais se composição funcional is used). This is one of the primary reasons why the Haskell-based Web server ("Warp") can be written em menos de 1.000 linhas de código enquanto o Servidor Web Apache requer cerca de 1,5 milhões de linhas de código. E o Warp é 100 vezes mais rápido que o Apache e muito menos vulnerável a muitos bugs e hacks de segurança. (Claro, todos os benchmarks dependem de como cada sistema é configurado, mas em geral, 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" no senso comum, mas tem constantes e recursos poderosos de recursividade e correspondência de padrões. Estes substituem a necessidade de loops for / while e variáveis mutáveis. De fato, a recursão e a correspondência de padrões são ferramentas muito mais eficientes para realizar as mesmas tarefas, e é por isso que a linguagem de programação Haskell não inclui loops for / while.

Haskell é preguiçoso. 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.)

Em suma: 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 Language page.

---

Notas:

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 Blake2 função de hashing e o Argon2 função de derivação de chave) são escritos em C, C ++ e Java e, ocasionalmente, precisamos construir interfaces entre eles e nossos componentes Haskell. No entanto, nos esforçamos para usar o Haskell para o maior número possível de componentes do Gini; e com o tempo, substituiremos bibliotecas de código aberto não-Haskell por bibliotecas de código aberto baseadas em Haskell e / ou nossos próprios componentes baseados em Haskell sempre que acreditarmos que isso tornaria nossos sistemas mais seguros e confiáveis.

3. Todos os softwares da Gini serão liberados para a comunidade de código aberto após o lançamento oficial do Gini BlockGrid e Troca Descentralizada Gini para o público em geral.

4. Há duas exceções para o recurso preguiçoso em Haskell: Estritas Bytestrings e Lazy Bytestrings. Bytestrings restritas representam dados como blocos de dados de 8 bits (1 byte) não são preguiçosos, 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.

---