Querido GheistLychis, primeiro quero agradecer por ter lido essa postagem que es · tocodando

Respondendo a "Concordo que frameworks são maneiras de reinven..." dentro da publicação Frameworks javascript são horríveis!?

tocodando

2 anos atrás

Querido GheistLychis, primeiro quero agradecer por ter lido essa postagem que escrevi com dedicação e que compartilha minha visão sobre o tópico.

O que eu penso é que a complexidade de desenvolvimento de software precisa diminuir.

Hoje em dia é muito mais doloroso desenvolver software do que há alguns anos.

Penso que as coisas precisam ficar mais fáceis, mas, o contrário tem ocorrido.

Penso que recursos do ES6 combinados ao ESBuild e PNPM por exemplo tornam possível criar microbibliotecas reativas de baixa complexidade facilmente.

Um reator de estado, uma função render e algo como HTM e literal template combinados ao ESBuild, e LiveServer resolveriam o inchasso terrível que os frameworks causam em projetos de médio e grande porte.

Dê uma olhada no repo a seguir e me diz por favor qual sua opinião sobre o minimalismo que essa biblioteca que criei proporciona.

Lembro que ela foi desenvolvida com javascript, possui tipos para typescript e é compatível com o padrão MFE (Micro-Frontend).

TerezzuJS

guaracy

2 anos atrás

Tem muito "eu acho" e "eu penso". Você poderiam trocar por uma afirmação sem nenhum problema. As grandes empresas querem manter os "clientes" e, facilitam alguma coisinha dificultando outras para manter esse elo mais forte. Vou deixar algum material para dar suporte para quem cai na real.

Se o Carl Sassenrath que é um cara fodão pelo background acha que as coisas estão excessivamente grandes e complexas então elas estão. O artigo Back to Personal Computing de JAN/1997 (há 26 anos) fala sobre o tema. Mais um para não dizer que é a opinião apenas de uma pessoa Simplicity, Please - A Manifesto for Software Development.

Mas é preciso saber definir o que é simples para ter um norte. Aí vem o artigo Definition of Simple para facilitar a vida. Então, a sintaxe tem grande importância na simplicidade da linguagem.

Mas programador parece que é meio masoquista. Aceita a complexidade maior de pontuação (chaves, vírgulas, ponto e vírgula e outras porcarias) que servem apenas para facilitar a vida de quem escreveu o compilador/interpretador. Parece que dá um certo poder. A maioria também não gosta de mudanças. Se sabe JS, quer usar para tudo. JS só é o que é pela venda casada. Tem um navegador, tem JS. Sinceramente eu não acho que escrevendo uma biblioteca mais simples e organizada em JS vá resolver muita coisa.

Tem um tópico aqui Estudando elixir, meu projeto nem tão secreto · KitsuneSemCalda · TabNews. Esperava ver mais comentários mas não tem nada. Só vejo dois motivos. Ou o pessoal já conhece ou o pessoal não se interessa por conhecer. Certamente é o segundo.

Teria inúmeros exemplos para mostrar mais, como citei o Carl no início, vou mostrar um em Red (baseada em Rebol do Carl). Como a comunidade é pequena, o desenvolvimento vai em ritmo de tartaruga (agora ainda está meio caranguejo para corrigir a decisão incorreta no início). Considero Alfa ainda mas é possível fazer um monte de coisas. É possível fazer uma calculadora GUI com 60 LOC? Sim!

Screenshot em diversos SOs, código e outras informações em Calculadora (Red + GUI) - o mais difícil é saber quando parar. Na época a versão para Linux ainda não mostrava os botões com o texto centralizado.

Código funcional em 280 caracteres (sem compactação) para caber em um tweet também é possível.

Bem, parar por aqui pois essa história dá um livro e é necessário falar sobre linguagens nascidas na década de 60.

tocodando

Autor

2 anos atrás

Isso que você falou tem muita verdade. Concordo!

Obrigado por compartilhar o que sabe conosco.

Quando quem escreve não é famoso poucas pessoas dão atenção.

Sobre Elixir não posso falar muito porque não conheço bem. Mas, me lembro que foi bastante falada algum tempo atrás por alguns produtores de conteúdo que acompanho.

Eu penso que a questão de sintaxe de fato é muito importante. Mas, acredito que o problema principal não é complexidade da própria linguagem.

Acredito que as pessoas estão gerando muita complexidade em torno das linguagens de desenvolvimento de software criando ferramentas que exigem documentação ainda maiores que a da própria linguagem para apoias o desenvolvimento.

Eu posso estar enganado sobre a forma como tenho visto as coisas acontecendo. Mas, se eu estiver certo, isso precisa parar.

Existem iniciativas que já estão funcionando. Deixei alguns links relacionados abaixo:

Seria muito bom seguir discutindo sobre isso com mais desenvolvedores. Quem sabe encontremos uma solução pensada por várias cabeças.

Você teria alguma sugestão?

GheistLycis

2 anos atrás

Incrível guaracy! Muito obrigado pelos links, abriu muito minha mente sobre o assunto. Com certeza visar o valor do produto final antes da tech/arquitetura do código é o melhor pra garantir um projeto simples e eficiente. Mas ainda me parece um tanto vaga a ideia de simplicidade que o Carl tanto defendeu. Ele cita a abstração como um ponto, o que é uma boa prática bem consolidada hoje como ele mesmo disse no artigo de 2001, mas não entendi direito o que quis dizer com o segundo ponto.

Muitas vezes, uma lógica complexa para ser abstrata demanda um código extenso - que poderia ser "simplificado" se aproveitando de recursos da framework ou de uma lib. Até onde podemos dizer que isso é uma boa prática, ou seja, que segue o princípio da simplicidade e não culmina num eventual cenário B do artigo que você referenciou que usa a empresa de carros como exemplo?

Vamos considerar o ponto que o próprio Carl levantou sobre como linguagens como C++ e Java acabam complicando algo que o Rebol faz em uma linha. Se eu implemento como padrão na empresa esgotar todos os recursos das techs que utilizamos em prol de código menos verboso e repetitivo, acabo com códigos complexos que dificultam a manutenção e fazem estagiários e júniores novos serem incapazes de compreender o que lêm. Se eu implemento a desmotivação do uso extensivo de recursos externos à linguagem, acabo com projetos muito maiores do que poderiam ser e que, querendo ou não, não vão se adequar aos padrões do mercado - o que afasta cada vez mais minha empresa dos devs que tenho interesse em contratar.

Essa conversa toda não se resumiria em dois caminhos: complexidade no micro e simplicidade no macro (o que o Carl defendia), ou o inverso (o que parece ser a tendência do mercado)? Não vejo como pode haver simplicidade em ambos sem utilizar dos recursos mais modernos. Afinal, é como eu tinha dito, querendo ou não a internet e o desenvolvimento não são mais os mesmos de 15, 20, 30 anos atrás. As necessidades são outras. Ser de tech significa estar constantemente atualizado. Isso só não precisa significar ser dependente das techs que usa. Acho que é possível sim ser auto suficiente e independente de frameworks sem se tornar um ermitão.

guaracy

2 anos atrás

Segunda parte (necessidades):

Eu não acredito que as necessidades sejam outras. Basicamente são as mesmas até de 60 anos atás ou mais. Tem um programa escrito em 1958 que estava rodando em 2015 (acredito que ainda está). O MOCAS do DoD dos EEUU. Na época dos mainframes as coisas eram mais backend/frontend. Se o backend funciona não existe necessidades de refazer tudo. Diferente de linguagens atuais (Python, por exemplo, que a versão 3 não executa os programas da versão 2) COBOL continua compilando programas escritos há décadas. Pascal também tem exemplos de programsa escritos na década de 90 que são compilados (tirando dependências de hardware). Hoje as coisas só estão mais rápidas (algumas como internet, processamento). Mas hoje existem processadores com múltiplos núcleos? Erlang trabalhava com isto há quase 40 anos. Segurança? Ada já tem mais de 40 anos. O pessoal fala "Não reinventar a roda". Todo o dia ela é reinventada com um pretexto diferente com as novas linguagens. Kotlin, Dart, Carbon, etc..
Em vez de ermitão, eu chamo de higlander. :D

Primeira parte (simplicidade e abstração):

Vamos considerar a linguagem que o Carl criou (REBOL).

Simplicidade e abstração andam de mãos dadas::

image: load %assets/images/icone.png
dados: load https://cdn.wsform.com/wp-content/uploads/2020/06/industry.csv
empregado: load https://docs.google.com/uc?export=download&id=1hIvdYeBd9NinV7CNcFjWXnBPpImKmYf3

Sem vírgula, parênteses, etc.. O espaço é o delimitador natural (como ler um livro). Simples.

Como abstração, load irá ler e interpretar um conteúdo não interessando o local e o tipo. Nos dois últimos casos, os arquivos serão processados e será criada uma estrutura de dados para a linguagem utilizar diretamente. Apenas como complemento, a barra / é usada para delimitar caminho e também é utilizada em variáveis (não é o termo utilizado por REBOL) como empregado/1/nome.

>> dados: load https://cdn.wsform.com/wp-content/uploads/2020/06/industry.csv
== [["Industry"] ["Accounting/Finance"] ["Advertising/Public Relations"] ["Aerospace/Aviation"] ["Arts/Entertainment/Pub...
>> length? dados
== 44

>> empregado: load https://docs.google.com/uc?export=download&id=1hIvdYeBd9NinV7CNcFjWXnBPpImKmYf3
== [#(
    id: 4051
    name: "manoj"
    email: "[email protected]"
    password: "Test@123"
    about: none
    token: "...
>> length? empregado
== 55

DSL (na linguagem são chamados de dialetos) é outra característica que abstrai e simplifica a programação. REBOL já vem com três grandes dialetos.

VID - para a criação de janela e widgets
DRAW - para desenho (linhas, circulos, etc.)
PARSE - substitui ER com diversas vantagens

Usando Red que é a linguagem que pretende ser a continuação de REBOL, se eu quiser mostrar uma janela com um botão que, quando pressionado mostre uma mensagem:

view [
    title: "titulo"
    button "clique-me" [
        alert "Hello"
    ]
]

Temos apenas os colchetes para delimitar os blocos. Fico me perguntando o motivo de flutter não ter uma sintaxe parecida. O pessoal de Clojure está tentando melhorar a sintaxe de Flutter mas não deverá adotada fora da linguagem.

page: read http://www.tabnews.com.br
rule: [thru <title> copy tit to </title>]
parse page rule
print tit

lê o conteúdo da página
especifica a regra : posiciona o ponteiro após (thru) a tag <title>, copia o conteúdo para a palavra tit até encontrar a tag </title>
parse aplica a regra na variável (poderia ser escrito tudo na mesma linha mas coloquei em page e rule para efeitos de legibilidade)

retorna TabNews: Conteúdos para quem trabalha com Programação e Tecnologia.

Na apresentação sobre JSON, pelo criador Douglas Crockford: The JSON Saga - YouTube, em 22:00 ele diz: "Rebol is a brillant language, and it's a shame it's not more popular, because it deserver to be.". Também não entendo o motivo de REBOL não ser mais popular e ter morrido. Talvez ser muito avançada para 1997?

Ficou meio longo. :D

tocodando

Autor

2 anos atrás

O que é ser um ermitão?

Eremita ou ermitão é um indivíduo que vive em lugar deserto, isolado, geralmente por motivo de penitência, religiosidade, ou simples amor à natureza, e o local de sua morada é chamado de eremitério.

Peguei a definição do termo que usou GheistLycis. Mas, novamente vou ter que discordar.

Minha praia atualmente tem sido javascript e em alguns casos acredito que usar um framework tem seu mérito. Mas, são casos de extrema complexidade.

Só acho realmente válido usar um framework se for extremamente complexo desenvolver uma solução própria.

Acredito que desenvolver uma solução própria reduz a complexidade, almenta a compreensão, maximisa habilidades, melhora muito a produtividade e permite total controle sobre os aspectos relacionados ao desenvolvimento do software.

O que mais tem por ai são bases de códigos enormes e softwares mediocres desenvolvidos com frameworks que não agregaram valor algum durante ou após o desenvolvimento do software.

Esse negócio de que tem que observar do ponto de vista do negócio para então desenvolver uma arquitetura com os frameworks xyz é a maior besteira.

O que eu tenho visto é muita gente escolhendo ferramenta por afinidade.

Tá é todo mundo querendo tirar o corpo fora e procurando um framework para dispejar o sucesso e também o fracasso quando surge.

Acredito que as linguagens e os patterns estão ai e podem facilmente substituir os frameworks.

GheistLycis

2 anos atrás

Me pareceu bastante o modo de trabalhar do React só que em MVC. É uma ideia boa. Não sei se já trabalhou com Django, mas ele segue muito essa ideia do minimalismo dentro do MVC. Recomendo, acho que vai gostar.

Você tem razão quando defende que tudo hoje tá ficando "overengenereed". Também me parece que as big techs jogam muito mais valor em cima das frameworks do que elas realmente tem e essa guerra dos frameworks é um grande estardalhaço que vive surfando em ondas de hype. Mas, querendo ou não, fato é que a internet e o desenvolvimento web não são mais os mesmos de 20 anos atrás e codar tudo só com os recursos da linguagem é inviável. Querendo ou não, é muito mais fácil ter uma interface reativa com React. Querendo ou não, é muito mais fácil ter um projeto robusto com Angular.

Eu particularmente sou da opinião de que mesmo que eu não PRECISE fazer X de uma maneira Y, eu vou preferir fazer se for o jeito mais "elegante" ou estiver de acordo com as boas práticas. Mas aí é só uma questão de vieses.

Acho que, independente das opiniões, o maior ensinamento que a gente pode tirar disso tudo é que um dev deve buscar acima de tudo ser auto suficiente e independente de tech/stack, mas saber fazer bom uso delas.

tocodando

Autor

2 anos atrás

Que resposta em GheistLycis!

Aqui no tabnews realmente tem pessoas incríveis com muito a compartilhar. Obrigado por isso.

Conconrdamos quase que totalmente.

Sinto como se fossemos quase que forçados a acreditar que usar algum framework é o correto, o melhor a fazer para desenvolver software.

Depois de viver essa última decada, cada dia mais acredito que o melhor é fazer uso de princípios ao invés de frameworks.

KISS, YAGNI e DRY são princípios interessantes e poderosos sozinhos, mas ainda melhores juntos.

Ao aplicá-los podemos colher benefícios incríveis:

Melhorar experiência do usuário.
Aumentar a eficiência da equipe ao longo do tempo.
Criar uma base de código simples, sustentável e flexível.
Evitar código legado sempre que possível.
Otimizar o custo de desenvolvimento.
Permite melhorar as formas de trabalho e comunicação, e aumentar a qualidade do software e a satisfação da equipe.

Podemos criar soluções elegantes apenas usando esses princípios e algumas ferramentas de apoio simples como ESBuild ou Parcel, Prettier e ESLint.

Abaixo os links de um post interessante a respeito de princípios e das ferramentas citadas. Vale coferir.