"Programming ... is now the province of those who prefer to work with thick compendia of details rather than wrestle with new ideas".
Backus seminal paper: Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs.
Ideas still valid today. And that was written before object oriented programming!
domingo, 12 de junho de 2016
domingo, 29 de maio de 2016
APIs replacing FTEs
de meu amigo Eduardo Carvalho: "Um conceito interessante, não tinha pensado nisso…"
APIs Are The New FTEs
Minha resposta, apresentando este work in progress (17/3/2016):
Importantíssimo este conceito. Nada novo no fundo, API existe desde que apareceu sistema operacional. O que é novo é a quantidade de APIs e isto que o artigo mostra bem, APIs que resolvem e disponibilizam uma solução.
Muito interessante o panorama do desenvolvimento de software agora. Tem frameworks, não de compliance e processos como ITIL ou PMI, mas espécies de bibliotecas com um problema resolvido. Exemplos: Django, Angular, Bootstrap, Node.js. Existem bibliotecas mesmo, libraries, de funções, que acompanham as linguagens, como .net da Microsoft. Tudo mais ou menos derivado do velho conceito de "módulo". Ou função, ou procedure, ou sub-rotina (Ô coisa antiga!) ou objeto.
Analisando melhor, os frameworks são em geral soluções prontas. O desenvolvedor se encaixa nela e acrescenta um pedacinho. As libraries são mais abertas, o desenvolvedor usa a função ou objeto que precisar.
Já as APIs são um pouco uma library, e mais do que isso, uma "máquina" diferente, com sua linguagem e seus comandos. Antigamente a impressora por exemplo era uma máquina diferente, e precisavamos de um driver para acionar. Agora temos "periféricos" muito mais ricos, com funções elaboradas, acessíveis via APIs. O artigo dá bons exemplos. Um exemplo forte é a API geoespacial do Google, em cima da qual todos os aplicativos tipo Uber, 99Taxi e outros são desenvolvidos.
Mundo interessante.
E para nós, interessantes as APIs para banco digital. IBM está lançando uma para blockchain.
Exemplo: Awesome Banking APIs
APIs Are The New FTEs
Minha resposta, apresentando este work in progress (17/3/2016):
Importantíssimo este conceito. Nada novo no fundo, API existe desde que apareceu sistema operacional. O que é novo é a quantidade de APIs e isto que o artigo mostra bem, APIs que resolvem e disponibilizam uma solução.
Muito interessante o panorama do desenvolvimento de software agora. Tem frameworks, não de compliance e processos como ITIL ou PMI, mas espécies de bibliotecas com um problema resolvido. Exemplos: Django, Angular, Bootstrap, Node.js. Existem bibliotecas mesmo, libraries, de funções, que acompanham as linguagens, como .net da Microsoft. Tudo mais ou menos derivado do velho conceito de "módulo". Ou função, ou procedure, ou sub-rotina (Ô coisa antiga!) ou objeto.
Analisando melhor, os frameworks são em geral soluções prontas. O desenvolvedor se encaixa nela e acrescenta um pedacinho. As libraries são mais abertas, o desenvolvedor usa a função ou objeto que precisar.
Já as APIs são um pouco uma library, e mais do que isso, uma "máquina" diferente, com sua linguagem e seus comandos. Antigamente a impressora por exemplo era uma máquina diferente, e precisavamos de um driver para acionar. Agora temos "periféricos" muito mais ricos, com funções elaboradas, acessíveis via APIs. O artigo dá bons exemplos. Um exemplo forte é a API geoespacial do Google, em cima da qual todos os aplicativos tipo Uber, 99Taxi e outros são desenvolvidos.
Mundo interessante.
E para nós, interessantes as APIs para banco digital. IBM está lançando uma para blockchain.
Exemplo: Awesome Banking APIs
sábado, 28 de maio de 2016
Was IT better before the 90s?
Good paper, personal experience of the author. Shows that IT in the 90s was almost a secret - so IT people were not professionals - and IT now is super-open - so again IT people are not professionals.
See preceding post.
Conclusion: IT people, developers and operation people must turn into serious professionals. This is a long road ahead.
See preceding post.
Conclusion: IT people, developers and operation people must turn into serious professionals. This is a long road ahead.
sexta-feira, 27 de maio de 2016
SICP or Programming by poking
Brilliant explanation by Sussman onwhy he stoped delivering his famous SICP course at MIT. Clear view on difference of software development 20 years ago (analysis-by-synthesis) and software today (poking gigantic libraries).
I do thing that today there is space for programming large systems bottom-up, using abstraction.
I do thing that today there is space for programming large systems bottom-up, using abstraction.
domingo, 29 de novembro de 2015
90% dos CIOs se sentem ignorados em relação às decisões de TI
http://computerworld.com.br/90-dos-cios-se-sentem-ignorados-em-relacao-decisoes-de-ti
Sim. O CIO se tornou um comprador de pacotes, não um desenvolvedor de software que faz a diferença. O mercado acabou com a oportunidade que a máquina universal permitiria. Não que seja fácil, mas aí o CIO faria a diferença.
A não componentização do mercado de software forçou esta evolução. Não há como o CIO comprar componentes e criar solução original. Não existem componentes, existem pacotes.
Tendência inversa a acompanhar: Componentizing the Web, http://queue.acm.org/detail.cfm?id=2844732
Sim. O CIO se tornou um comprador de pacotes, não um desenvolvedor de software que faz a diferença. O mercado acabou com a oportunidade que a máquina universal permitiria. Não que seja fácil, mas aí o CIO faria a diferença.
A não componentização do mercado de software forçou esta evolução. Não há como o CIO comprar componentes e criar solução original. Não existem componentes, existem pacotes.
Tendência inversa a acompanhar: Componentizing the Web, http://queue.acm.org/detail.cfm?id=2844732
sábado, 16 de maio de 2015
Chaitin, mais uma vez!
Orsoni, muito obrigado pelo belo presente. Fantástico artigo. Gostei muito da elaboração teórica do conceito de randomness, e ligação com complexidade, com teoria dos algoritmos, e finalmente com teoria da informação. Tudo isso saindo do teorema de Gödel! Maravilha. E ainda dizem que o teorema de Gödel foi um desastre para muitos matemáticos. Ao contrário, pode-se dizer que a computação, via Turing, foi consequência do teorema de Gödel.
[...], tem mais conexões incríveis. Chaitin se refere a Kolmogorov, que lá atrás definiu uma máquina, máquina de Kolmogorov-Uspensky, equivalente à máquina de Turing. Recentemente lendo sobre programação funcional encontrei material sobre teoria dos tipos (como tipos de dados em uma linguagem de programação), baseados no trabalho de um lógico sueco Per Martin-Löf, que foi discípulo de Kolmogorov.
Tudo se liga!
[...], tem mais conexões incríveis. Chaitin se refere a Kolmogorov, que lá atrás definiu uma máquina, máquina de Kolmogorov-Uspensky, equivalente à máquina de Turing. Recentemente lendo sobre programação funcional encontrei material sobre teoria dos tipos (como tipos de dados em uma linguagem de programação), baseados no trabalho de um lógico sueco Per Martin-Löf, que foi discípulo de Kolmogorov.
Tudo se liga!
Assinar:
Postagens (Atom)