Pitch: A linguagem de programação Spiral [ChatGPT]

Sobre a dependência do ecossistema .NET, é algo natural inicialmente pois a linguagem é escrita usando F# e compila pra F# por padrão, porém ao compilar pra outros backends como Python ou C++/CUDA, o resultado não carrega nenhuma dependência além do seu ecossistema de destino. Por mais que a sintaxe seja uma cópia de 90% da sintaxe de F#, as funcionalidades de OOP para compatibilidade com C# e outras particularidades do .NET não foram adicionadas, dando lugar para recursos de type system mais avançados e tornando Spiral uma linguagem universal, permitindo compilar pra qualquer linguagem ou bytecode sem muitas adaptações, incluindo computação quântica como mencionado no chat. O plugin do VSCode é necessário para ergonomia ao escrever código, normal pra qualquer linguagem em uma IDE. O plugin executa uma API na porta 13805, tudo que a UI do VSCode faz ao interagir com os projetos invoca a mesma. Utilizei essa API pra criar um pipeline e2e pra compilar Spiral para Rust e testar smart contracts no GitHub Actions, essa mesma estratégia poderia ser utilizada pra adicionar suporte às IDEs da JetBrains ou no Livebook do Elixir utilizando Smart Cells por exemplo. Convido você a explorar uma prova de conceito de rolagem de dados fullstack que utiliza GitHub Actions para testes e deploy: 1. Frontend Implementado - https://i574n.github.io/polyglot/apps/dice/ui/dist/popup.html : Um frontend web exibindo transações on-chain de um contrato inteligente de rolagem de dados na NEAR Protocol, buscando as informações em sua API pública. 2. Código do Frontend - https://github.com/i574n/polyglot/blob/main/apps/dice/ui/src/dice_ui.spi : Código-fonte da função main do frontend Spiral, o body é montado aqui, mostrando como é compilado para Rust e integrado em um framework web moderno. 3. Código do Contrato Inteligente - https://github.com/i574n/polyglot/blob/main/apps/dice/contract/src/lib.rs : O código-fonte do contrato inteligente, com a linha 139 mostrando a função de rolagem em Spiral sendo chamada por Rust na função generate_random_number. 4. Declaração da Função em Spiral - https://i574n.github.io/polyglot/apps/dice/dice.dib.html : O código Spiral declarando a função de rolagem chamada por Rust. Estes links oferecem uma visão abrangente de como a linguagem funciona em uma aplicação no mundo real. Se você abrir o console nas ferramentas de desenvolvedor do navegador no frontend implementado, verá mensagens correspondentes ao código-fonte de montagem do body, ilustrando o pipeline de compilação em ação.

Erlang é uma linguagem dinâmica e Elixir também. É um wrapper que se baseia na sintaxe de Ruby, resolve muitos problemas, mas ainda dinâmica. Outras linguagens também estão sendo criadas para se aproveitar da Erlang VM, como Gleam, que é estática porém sem metaprogramação, sendo não tão genérica como Spiral. A dor se chama “Modelagem de Domínio”. O objetivo é escrever todas as regras de negócio e algoritmos críticos utilizando Tipos Soma (também chamados de ADTs/Algebraic Data Types). Os enums de Rust possuem esse poder, só que a linguagem não é primariamente funcional e possui uma sintaxe semelhante a C (como Gleam). Acredito que uma modelagem de domínio adequada deve utilizar linguagens estáticas que seguem a teoria Hindley-Milner, como F#, OCaml, Haskell e Spiral. Seguem dois blog posts que abordam o assunto: - https://fsharpforfunandprofit.com/posts/ten-reasons-not-to-use-a-functional-programming-language/ - https://fsharpforfunandprofit.com/posts/type-size-and-design/ Ao utilizar Spiral pra compilar pra Rust, sua funcionalidade de inlining duplica código escrito uma só vez pra diferentes seções da stack, perdendo a necessidade de “clonar” memória em algumas partes. Preciso testar e documentar melhor essa parte, mas é algo que percebi nos meus experimentos, utilizar Rust e ao mesmo tempo dar “bypass” no borrow checker, onde o output seria mais imutável. Isso é algo bom? Acho que sim. A mesma abordagem levaria a ganhos de performance ao rodar esse mesmo código compilado pra Elixir na Erlang VM. Resumindo, a ideia é escrever aplicações utilizando uma sintaxe ergonômica e universal pra compilar pra diferentes ambientes de execução de acordo com a necessidade. Utilizei Rust e Elixir como exemplo porque resolvem a maioria dos problemas atuais, poderia ser qualquer destino, como Kotlin, Flutter e Java, pra auxiliar na migração de um legado. Fica a indagação: considerando o blog post abaixo, em questão de reuso de código, como seria se o Discord utilizasse Spiral pra compilar pra Elixir e Rust? https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users

Exemplo de uma macro em Elixir pra realizar inlining de soma de listas com valores conhecidos em compilação: ``` defmodule MyList do defmacro sum_list(list) do quote do unquote(Enum.reduce(list, 0, &(&1 + &2))) end end end IO.inspect MyList.sum_list([1, 2, 3, 4, 5]) ``` Resultado da compilação em Elixir. A cada compilação/execução de projeto, o código acima é convertido em Erlang VM bytecode, assim economizando realizar a soma em toda execução da função em requests de API, timers, etc. ``` IO.inspect 15 ``` O código Spiral abaixo geraria `15` na linguagem escolhida, contando que um backend para tal tenha sido implementado. ``` inl sum list = list |> listm.fold (+) 0 inl main () = [1; 2; 3; 4; 5] |> sum ``` O código abaixo também geraria `15`, mostrando que transpilar não é o termo correto, e sim compilar, diferente de TypeScript para JavaScript. ``` type seq dim el = dim -> option el inl fold fn init seq = inl rec loop acc n = match seq n with | Some x => loop (fn acc x) (n + 1) | None => acc loop init 0 inl sum seq = seq |> fold (+) 0 inl main () = fun n => if n < 5 then n + 1 |> Some else None |> sum ``` Quando nem todos os dados das listas são conhecidos, Spiral tem a grande vantagem de pré computar o que é possível e gerar código normal para os backends escolhidos. Usando exclusivamente Elixir para escrever projetos, somente o código original é submetido à repositórios como Git e compilado a cada execução. Com Spiral o resultado da compilação também é submetido, os arquivos .ex e .rs gerados seriam versionados e incluidos manualmente em respectivos projetos existentes. Flags em código podem ser utilizadas pra gerar instruções diferentes de acordo com backend, similar com escrever Flutter ou React Native pra em teoria gerar Kotlin e Swift, porém com uma sintaxe pensada em programação funcional moderna, permitindo uma melhor customização. Sobre redes neurais, poder gerar código legível para várias linguagens permite que aconteça o que você sugeriu, o output seria dados confiáveis pra treinamento. Não só isso, como a linguagem foi feita para implementar modelos de deep learning que utilizam essa capacidade de executar lógicas complexas em compilação pra “alocar” a exata quantidade de memória necessária – mais stack e menos heap, permitindo a álgebra linear ser executada em chips menos genéricos que GPUs. Além dessa capacidade de especialização em alguma tarefa determinada para hardwares pré-moldados, implementações de modelos de IA do zero usando Spiral também poderiam ser arquitetadas pra escrever e reescrever o próprio código, encontrando melhores formas de gerar output pra seus diferentes backends. Os modelos em Python de hoje são muito focados em dados e escalabilidade do processamento dos mesmos, podem ter até consciência do próprio código, mas sem influenciar a decisão de hiper parâmetros em escopo estrutural. Não tenho o treinamento formal pra explicar melhor essa parte, talvez esteja falando besteira, mas já consegui ver vantagens ao implementar coisas mais simples como smart contracts. Quem sabe até seja possível integrar IA e blockchain no futuro, da pra viajar bastante. --- Tive que responder usando outra conta por causa desse erro :( `Não é possível publicar porque há outras publicações mal avaliadas que ainda não foram excluídas. Exclua seus conteúdos mais recentes que estiverem classificados como não relevantes. 9d03783c-15b0-42fa-9fc4-f3f90d4136f9`