Executando verificação de segurança...
0

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

E aí, pessoal! Hoje estou aqui para jogar uma ideia no ventilador e ver o que acontece. Vocês já pensaram no que aconteceria se misturassem Rust e Elixir numa mesma sintaxe? Pois é, eu tenho mergulhado nesse universo e, sinceramente, parece que estamos diante de algo que pode chacoalhar desde blockchain até IA e robótica!

Saca só: temos aqui a linguagem Spiral com suas manobras de metaprogramação de outro mundo, o Rust garantindo que não vamos fazer besteira com a memória, e o Elixir para manter tudo rodando liso e distribuído. Eu sei que soa meio "vendedor de ideias milagrosas", mas dá uma olhada nesse link que discute o potencial a fundo: https://chat.openai.com/share/1ad5a1de-ca7a-4d26-8594-f1901c56281c

Ainda não tenho um produto final ou plano de negócio em mãos, mas estou procurando aqueles com a coragem e a visão para explorar esse território desconhecido. Quem sabe a gente não monta uma equipe e começa a botar a mão na massa aqui no Brasil?

Agradeço e aguardo ansioso pelos pitacos de vocês.

Carregando publicação patrocinada...
1

O problema é que depende 100% de um plugin de VSCode para funcionar, e aparentemente utiliza o ecossistema do .NET para que tudo pare em pé.

Acho que vale a pena observar sim. Tem coisas interessantes aqui. Obrigado pela dica.

2

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.

1

Pelo que li aqui me parece que você propõe que seja criada uma nova linguagem de programação que se chamaria "Spiral" e juntaria as capacidades de Rust e Elixir nela própria?

Se for isso eu me pergunto o "Porquê" Por que criar essa nova linguagem?

Qual a "dor" que essa linguagem resolveria?

Essas perguntas minhas são bem alto nível porque ainda tem perguntas como:

1 - Elixir roda no Erlang... logo o Erlang VM em si que tem o "poder", O Elixir é como se fosse um Wraper que usa o poder do Erlang.

2 - O rusto compila para código de máquina, mas a features dele são únicas, não tem Garbage Collection, tem conceitos únicos de Borrow Checker ... Os dados podem ser alterados com "mut" e "emprestados".

Essas duas linguagens tem conceitos que não se dão bem juntos! Para o erlang garantir tudo que você mencionou ele não pode emprestar nada para ninguém com variáveis e tudo precisa ser imútavel.. Isso vai contra a política do Rust e vice-versa.

Criar uma coisa como essa que você ta falando é "estranho", tem que ver uma razão excelente para pessoas dedicarem tempo em uma tecnologia como essa.

1

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:

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

1

Já abordaram a questão do Elixir, mas gostaria de perguntar também:

Como se dá, ou poderia ser feita, essa implementação onde Spiral é transpilada para Elixir? Elixir roda em Erlang... logo, se uma preocupação é eficiencia, linguagens com backend separado não seriam "menos" eficiente em tempo de compilação?

Sim, entendo a complexidade da compilação e sei que nenhum compilador é 100% eficiente. Mas toda linguagem compilada deve prezar pela eficiencia em compilação. O proprio Rust trás inumeros beneficios e inovações, mas é lento em compilação pois o compilador faz muitas checagens para manter tudo rodando legal. O propio binario de Rust é maior em comparação com outras linguagens, como a santa trindade(ASM,C,C++).

Digo isso porquê Spiral tem o foco em juntar tudo o que ha de bom em outras linguagens(tipo as meninas superpoderosas kkk) mas a complexidade é enorme. Transpilar codigo e rodar é uma coisa, agora compilar de verdade é outra... Por exemplo, como poderíamos ter um sistema distribuido eficiente se o programa deve ser portado para Elixir, que será transformado em codigo para a maquina Erlang? E o Rust entra onde? Poderiamos usar indicador durante o codigo?(tipo, @cod_erl e então aquele script seria portado para a maquina Erlang, ou algo assim).

Isso não é maquiar um script tal qual o Typescript faz para o javascript? No fim tudo não seria Erlang ou Rust?(levando em consideração a diferença entre as duas langs, acho beem dificil criar algo no meio delas, não que seja impossivel)

Minha ultima indagação: Não seria melhor criar uma rede neural que transpile o codigo Spiral para qualquer linguagem? kkkk sério, seria o primeiro compilador inteligente do mundo, e mataria um monte dessas questões acima :)

particularmente gostei da idéia, acho que tem muita coisa para se discutir, mas pode ser um projeto bem legal!

1

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