Do It Yourself (ou não)

Há algum tempo tenho feito alguns “experimentos” no meu canal do YouTube, afim de aprimorar também essa plataforma para que se torne um complemento desse blog.

Algumas lives sobre programação e principalmente, alguns mini projetos relacionados ao MSX e computação em geral, tem sido feitos nesse interim, como a live onde demonstrei o código da engine 3D portado a partir do vídeo e código apresentados em “Code it yourself – First person shooter” do excelente canal do Javidx9.

Pop!Live Stream Code It yourself-First person shooter on MSX-TR (Quick and simple Turbo Pascal 3.3F)
Pop! Live Stream – Code It yourself – First person shooter (Quick and simple Free Pascal)

Hoje finalmente liberei mais um formato, que acredito ainda precisar de aprimoramentos de maneira geral.

É o quadro “Faça você mesmo (ou não)”, para isso já até criei a playlist só para facilitar a busca nos vídeos dessa série em meu canal.

Entretanto podemos dizer que esse formato ainda é WIP (Work In Progress) e que estaremos ajustando nos próximos vídeos.

Toda sugestão é bem vinda.

MSX 1.1 Expert XP800 Capacitor Recap e CPU upgrade (Z80 6Mhz)

[]’s
PopolonY2k

No principio era o binário.

No livro de Bytesis capitulo 1 está escrito.

Versículo 1
E no principio era o binário e o binário era de difícil compreensão.
Então se criou os mnemônicos para facilitar a montagem de programas em binário e chamou isso de assembly.

Versiculo 2
E viu que assembly era bom, era rápido e enxuto mas ainda assim era difícil e causava muitos travamentos por ter acesso direto ao hardware.

Versiculo 3
Então chamou o profeta Denis Ritchie e disse, “Ide e desenvolvei uma linguagem abstrata que facilite a integração entre alto nível e baixo nível. E sendo essa linguagem de médio nível, a chamarás linguagem C”

Versículo 4
E o profeta Ritchie assim o fez e C era rápida e tão boa quanto o assembly e viu que era bom.

Versículo 5
Então chamou o profeta Bjarne Stroustrup e ordenou, “Ide e desenvolvei uma linguagem igualmente abstrata com possibilidade de encapsulamento e polimorfismo infinitos, tendo as mesmas especificações básicas de C, conforme eu ordenara anteriormente, e que seja igualmente rápida como as antecessoras.”

Versículo 6
E assim o profeta Stroustrup o fez conforme ordenado.
E vendo o criador seu feito disse, “Bendito sejas entre os povos e que seus feitos sejam conhecidos perpetuamente até o final dos tempos”.
E chamou essa linguagem de C++.

Versículo 7
E vendo que os feitos dos profetas eram bons e que davam bons frutos, o criador lhes deu uma última ordenança.
“Ide e divulgai todo o seu conhecimento ao redor do planeta, para que as futuras gerações saibam que eu estive contigo desde a criação, porém não crieis linguagens baseadas em máquinas virtuais e bytecodes, pois se assim tu o fizeres, certamente morrereis”.

[]’s
PopolonY2k

Desenvolvendo com OpenMSX

Acredito que toda, ou grande parte da comunidade MSX conheça o excelente emulador OpenMSX, principalmente os usuários de Linux e MacOSX.

Bom, confesso que depois de voltar a ativa no mundo MSX, eu utilizo uma máquina real em 100% do meu tempo desenvolvendo coisas, até porque não jogo no MSX há anos. Entretanto desde o último ano, não tenho conseguido tempo para estar à frente da minha máquina de desenvolvimento preferida, que é o meu MSX TurboR A1ST com 1MB de RAM, IDE Tecnobytes com 8GB de Compact Flash, Expansor de slots ACVS, placa de rede Obsonet Tecnobytes, dentre outras coisas que estão conectadas nessa máquina.

Desde o início dos anos 2000, senão me engano lá por 2002 ou 2003, quando a “batalha de emuladores” era mais intensa entre os RuMSX, ParaMSX, fMSX e seus mais diversos sabores, duas opções “definitivas” começaram a se fundamentar no meio da comunidade MSX mundial e hoje reinam absolutas em sua preferência.

Estou falando do BlueMSX e do OpenMSX.

BlueMSX LogoBlueMSX logo

Usei muito o BlueMSX, principalmente quando jogava no emulador, mas como desenvolvedor, percebi desde cedo que o OpenMSX se tratava de um projeto mais aberto e poderoso no que diz respeito a sua utilização no desenvolvimento de novos projetos, sejam de hardware ou de software, além do fato de seu projeto ser extremamente bem feito, com um código muito bem escrito e documentado, além de ser multiplataforma.

openmsxOpenMSX logo

OpenMSX como plataforma de desenvolvimento.

Além de já ter sido vastamente utilizado como plataforma para desenvolvimento de hardware, em projetos como o MSXARM, o OpenMSX é uma excelente plataforma de desenvolvimento de software, principalmente pelo fato do mesmo emular quase todos (ou todos) os dispositivos que podem ser conectados a um MSX real, como os famosos LaserDiscs, por exemplo.

Por esse motivo e também incentivado pela série que vem sendo escrita no site de Javier Lavanderia, sobre programação para MSX utilizando MSX C, eu decidi que era hora de testar o nível de compatibilidade do OpenMSX, bem como todas as capacidades desse emulador, no desenvolvimento de novos projetos para MSX.

OpenMSX console

O OpenMSX possui um console embutido, que você ativa toda vez que pressiona F10 e a partir daí, em paralelo com a emulação, é possível interagir com a máquina utilizando um conjunto extenso de comandos disponíveis no emulador, conforme pode ser visto nesse link aqui.

Inclusive, via comandos Tcl, você pode controlar o emulador utilizando uma interface através de alguns meios de comunicação disponíveis no emulador, como pipes, named pipes, a saída padrão (stdio), TCP Sockets e UNIX domain sockets, ou seja, é um emulador modular ao extremo, permitindo até que você escreva seu próprio launcher, caso não esteja satisfeito com o OpenMSX Catapult, que para mim poderia ter sua interface tão poderosa e até mais do que a do emulador BlueMSX por exemplo.

Abaixo segue um excelente vídeo demonstrando essa integração do OpenMSX com Tcl/Tk, através do console de Tcl embutido nesse emulador.

Integrando OpenMSX com Tcl

Preparando seu disco.

Apresentado o console do OpenMSX, agora vale a pena citar um comando muito especial e poderoso, o diskmanipulator.

Resumidamente, o diskmanipulator é capaz de criar imagens de disco bem como gerenciar seu conteúdo. As imagens criadas são compatíveis com FAT12 e FAT16 e poderão ser utilizadas no OpenMSX como floppy disks comuns e também como hard disks  IDE.

OpenMSXOpenMSX console

A página de instruções do diskmanipulator contém diversas explicações de como criar imagens para discos flexíveis de 720Kb, discos rígidos com partições de FAT12 e FAT16, bem como instruções de como importar dados para esses discos a partir do disco local da máquina host em que o OpenMSX está sendo executado.

Como o objetivo desse post é justamente apresentar o OpenMSX como uma plataforma real para desenvolvimento de softwares para MSX, então preparei um disco com duas partições, sendo a primeira FAT12 e outra FAT16, com diversos softwares específicos para o desenvolvimento de software no MSX. Segue abaixo a lista do que atualmente está contido no disco criado e pronto para usar:

DRIVE A: (FAT12)

MSXDOS2 operating system compatible

[DEV]     (Editors, compilers, assemblers and general purpose development tools)
—|———[M80] (Microsoft/ASCII – Z80 Assembler)
—|———[DEVPAC80] (HiSoft Z80 Assembler)
—|———[TP33] (MSX Computer club Turbo Pascal 3.3 compiler)
—|———[TP3] (Borland Turbo Pascal 3.00A compiler)
—|———[TED] (MSX2.0 and higher Text Editor)
—|———[APED] (MSX2.0 and higher Text Editor)
—|———[TOR] (MSX1&2 text editor)

DRIVE B: (FAT16)

[PROJECTS]   (Projects source code)
——-|—-[PASCAL] (Turbo Pascal compatible source code)
——-|———|
——-|———|——[PCX]  (Source code for PCX file format handling)
——-|———|——[INLASS] (Turbo Pascal Inline assembler)
——-|———|——[MKINL] (Another Turbo Pascal Inline assembler)
——-|———|——[PMLINK] (Another Turbo Pascal Inline assembler)
——-|———|——[INLINE] (Another Turbo Pascal Inline assembler)
——-|———|——GRAPH.INC (Graphical library for MSX)
——-|———|——PARSE.INC (Command line parameter parser)

Lembrando que essa é apenas uma configuração de disco inicial em que ainda estou trabalhando, portanto no futuro certamente serão adicionados a esse hard disk, os pacotes do MSXC (1 e 2), HiSoftC, dentre outras excelentes ferramentas destinadas ao desenvolvimento de software para o MSX.

Baixando e usando o hard disk

O harddisk citado acima, pode ser encontrado nessa URL aqui, e de fato é um compartilhamento de minha pasta do DropBox que deixo disponível à comunidade. Os arquivos dessa URL serão atualizados com o tempo, visando a adição de novos compiladores e ferramentas de desenvolvimento para a plataforma MSX.

Nesse mesmo link você encontrará dois arquivos, os quais descrevo abaixo:

dev_hd.dsk -A imagem de 64MB com as duas partições (A: FAT12 e B: FAT16) pronta para uso no OpenMSX;
dev_hd.tcl  – Script Tcl utilizado para dar boot no OpenMSX, usando a imagem de disco acima;
Passos para utilização do disco no OpenMSX:
    1. Baixe esses dois arquivos em qualquer diretório de sua máquina. O único ponto de atenção a ser tomado é que esses dois arquivos devem estar no mesmo diretório pois o script TCL <dev_hd.tcl>, busca pela imagem do hard disk no mesmo diretório em que o script está sendo executado;
    1. Abra o OpenMSX utilizando a sua configuração de máquina preferida;
    1. Com o OpenMSX rodando, pressione a tecla F10, para invocar o console Tcl do OpenMSX;
    1. Já na tela do console, digite o comando abaixo:
      source <caminho_onde_você_baixou_a_imagem_de_disco_e_o_arquivo_tcl/dev_hd.tcl>
    1. Pressione <ENTER>
  1. Divirta-se 🙂

Pronto, o seu OpenMSX irá reiniciar já fazendo boot com a imagem de hard disk que você baixou no link acima.

Isso é apenas uma pequenina amostra do potencial desse que, para mim, é o melhor e mais completo emulador da plataforma MSX, na atualidade.

Fiquem antenados nos novos updates da imagem de disco, que disponibilizei no link do Dropbox.

[]’s
PopolonY2k

Referência na internet

OpenMSX home
http://openmsx.org/

Linux (Wikipedia)
https://en.wikipedia.org/wiki/Linux

MacOSX (Wikipedia)
https://en.wikipedia.org/wiki/OS_X

RuMSX home
http://www.lexlechz.at/en/software/RuMSX.html

ParaMSX (MSX.org)
http://www.msx.org/news/emulation/en/paramsx-048b

fMSX home
http://fms.komkon.org/fMSX/

BlueMSX home
http://www.bluemsx.com/

MSXARM primeiro teste de hardware (PopolonY2k Rulezz)
http://www.popolony2k.com.br/?p=2074

LaserDisc (Wikipedia)
https://en.wikipedia.org/wiki/LaserDisc

Relearning MSX (Lavanderia.net)
http://www.lavandeira.net/relearning-msx/

OpenMSX console commands.
http://openmsx.org/manual/commands.html

Tcl Tk home
https://www.tcl.tk/

Controlling OpenMSX
http://openmsx.org/manual/openmsx-control.html

Pipe communication
http://www2.cs.uregina.ca/~hamilton/courses/330/notes/unix/pipes/pipes.html

Named Pipes (Wikipedia)
https://en.wikipedia.org/wiki/Named_pipe

Network socket (Wikipedia)
https://en.wikipedia.org/wiki/Network_socket

UNIX domain sockets
https://en.wikipedia.org/wiki/Unix_domain_socket

DiskManipulator (OpenMSX)
http://openmsx.org/manual/diskmanipulator.html

PopolonY2k’s OpenMSX development hard disk (DropBox sharing)
https://www.dropbox.com/sh/smo2dz1kwl6wvfm/AAAYfFbZGjoksmoIRE4TlwPGa?dl=0

DropBox website
http://www.dropbox.com

10 regras da NASA para desenvolver código seguro.

Recentemente postei nas comunidades GDMSX do FaceBook e do G+ um texto bem interessantante sobre algumas dicas da NASA de como desenvolver código seguro.

Isso é muito interessante principalmente para aqueles que desenvolvem código para sistemas/dispositivos que nunca pode se dar ao luxo de uma exceção não tratada ou um core dump, comuns no mundo UNIX ou os famosos GPF’s bem conhecidos para programadores do mundo Windows.

Alguns membros da comunidade GDMSX me pediram para traduzir, então eu decidi fazer uma tradução livre, com algumas considerações pessoais que estão marcadas no texto como “(*) Notas do tradutor” 🙂 .

Vamos ao texto.

10 regras da NASA para desenvolver código seguro.

NASA Computers
NASA Computers

A NASA tem escrito software de missão crítica para a exploração espacial por décadas e agora a organização está transformando esses guias de programação em um padrão de desenvolvimento de software da indústria.

O laboratório de propulsão a jato da NASA para softwares confiáveis (JPL), recentemente publicou um conjunto de guias de programação (code guidelines), “Potência de 10 – Regras para o desenvolvimento seguro de código crítico“. O autor do texto, o cientista chefe Gerard J. Holzmann, explicou que a quantidade de codificação existente é inconsistente e cheia de regras arbitrarias, raramente permitindo tarefas essenciais como verificação de conformidade de código baseado em ferramentas de checagem de código. Os guias existentes, ele disse, inundam os programadores com regras vagas, diminuindo a qualidade do código da maioria das aplicações críticas.

“Projetos mais sérios de desenvolvimento de software usam guias de codificação,” escreveu Holzmann. “Esses guias destinam-se a firmar as regras básicas para o qual o software está sendo escrito: como ele deveria ser estruturado e quais características da linguagem deveriam e não deveriam ser usadas. Curiosamente, existe um pouco de consenso sobre o que é um bom padrão de codificação.”

 Holzmann definiu 10 regras rígidas para o desenvolvimento de software, tendo em mente a segurança do código. As regras foram especificamente escritas levando em consideração a linguagem C (uma linguagem recomendada pela NASA devido a sua longa história no desenvolvimento de software crítico e seguro e também pelo extensivo suporte de ferramentas a essa linguagem como por exemplo analisadores de código, depuradores, ferramentas de testes, dentre outras), embora essas regras possam ser facilmente generalizadas para codificação em qualquer outra linguagem, principalmente as que tem forte similaridade com C no nível de estruturação, como é o caso de Pascal e suas variantes.

  1.  Restrinja toda a construção de seu código a um fluxo de controle muito simples. Não use declarações GOTO, construções com setjmp ou longjmp, ou recursividade direta ou indireta;

    (*) Nota do tradutor:
    Quanto ao GOTO não é preciso nem escrever muito a seu respeito pois um de seus “males”, que é o de deixar o código confuso através de saltos incondicionais, já são amplamente conhecidos ao longo dos anos. O mesmo acontece com a dupla setjmp/longjmp que causam o mesmo efeito do GOTO, mas infelizmente esse recurso ainda é muito defendido por programadores experientes de C que muitas vezes se recusam a abandoná-los.
    Quanto à recursividade direta ou indireta, realmente essas tornam o código mais complexo entretanto por diversas vezes o seu código pode se tornar mais eficaz do que utilizando métodos tradicionais para resolução de um problema. Um exemplo é o algoritmo de multiplicação reconhecidamente veloz conhecido como algoritmo de Karatsuba e que é recursivo.
    Eu particularmente sugiro que se utilize métodos recursivos pequenos e de baixa complexidade, pois dessa forma pode-se evitar possíveis pontos de falhas que são invisíveis na maioria das vezes em tempo de desenvolvimento, mas que são comuns em uma situação de missão crítica.
    Quando se optar por implementar métodos recursivos, tenha em mente que a cobertura de seus testes unitários deverá ser extremamente abrangente a ponto de se testar as mínimas situações de falha.

  2. Todos os loops devem ter um limite superior fixo. Isso deve ser trivial para uma ferramenta de checagem que prove, estaticamente, que um dado limite no número de iterações não pode ser excedido. Se o limite do loop não puder ser comprovado estaticamente, a regra é considerada violada. Caso os limites sejam violados, o método deverá disparar um assert a ser verificado pelo chamador.

    (*) Nota do tradutor:
    Essa regra pode ser checada através da implementação de testes unitários com os devidos cenários mapeados.

  3. Não use alocação dinâmica de memória após a inicialização.

    (*) Nota do tradutor
    Realmente alocação dinâmica em linguagens que não são gerenciadas por um Garbage Collector é algo crítico e que deve ser utilizado de maneira cuidadosa, principalmente para principiantes no desenvolvimento de software. No artigo original, o autor cita diversos dos problemas conhecidos em se utilizar alocação dinâmica como a não liberação de recursos corretamente, o que causam os famosos vazamentos de memória ou memory leaks, e também cita sobre o cuidado de não ultrapassar os limites da memória alocada, esse último sendo também um problema quando se está usando memória alocada estaticamente em C.
    Entretanto existem casos que a alocação dinâmica é necessária e não há como escapar, nesses casos o mais comum a se fazer é alocar o buffer desejado em um ponto único, fazer toda e qualquer referência a esse buffer através de ponteiros passados para as funções que irão manipulá-lo e por fim liberá-lo nesse mesmo ponto único em que foi alocado, de preferência. Dessa forma você restringe toda a construção de seu código a um fluxo de controle muito simples, que é exatamente o primeiro item sugerido por esse guideline.
    Muitos dos desenvolvedores de softwares novatos sequer tem conhecimento de problemas de fragmentação de memória, decorrentes do abuso excessivo de alocação e liberação dinâmica de memória, principalmente em dispositivos de missão crítica que geralmente são hardwares embarcados dedicados e com recursos limitadíssimos de memória e armazenamento.

  4. Nenhuma função deve ser tão extensa que não possa ser impressa em uma única folha de papel (em uma referência ao formato padrão com uma linha por instrução e uma linha por declaração). Tipicamente isso significa não mais do que 60 linhas de código por função.

    (*) Nota do tradutor
    Manter o código com poucas linhas por função é sempre uma excelente prática pois facilita na manutenção do mesmo, entretanto algumas vezes principalmente em se tratando de código que gerencia máquinas de estado complexas, é melhor que a função fique um pouco maior do que as 60 linhas sugeridas ao invés de quebrá-las em mais funções para que comporte as 60 linhas, pois se ganha em performance, uma vez que se reduz o custo das passagens de parâmetros entre funções, ainda mais em se tratando de passagem de parâmetros de grandes estruturas por valor, que nesse caso é também uma péssima prática e que deveria ser substituída por passagem por referência ou ponteiro. Em linguagens orientadas a objeto, a regra de 60 linhas por método (função) é mais plausível e fácil de se atingir por conta da capacidade de encapsulamento dessas linguagens.

  5. A quantidade de asserts por função deve ser de no mínimo duas por função. Asserts não devem causar nenhum efeito colateral no código e deveriam ser definidos como testes booleanos.

    (*) Nota do tradutor
    Linguagens com um rico pré-processador como são C e C++ são propensas a inserção de asserts que estarão ativos dependendo do modelo de compilação em que o  binário/executável foi gerado, com isso pode-se gerar compilações de software específicas para testes.

  6. Dados devem ser declarados no menor nível de escopo possível.

    (*) Nota do tradutor
    O uso de variáveis globais é algo que vem sendo desestimulado no decorrer dos anos, pois é reconhecido que manter os dados encapsulados em escopos cada vez menores é um grande facilitador na hora de se descobrir bugs ou realizar qualquer tipo de manutenção ou melhorias no código, então declarar variáveis específicas de cada escopo é uma boa prática de programação.

  7. Cada função chamadora deve checar o retorno de funções não void (que retornam valores) e a validade dos parâmetros devem ser checadas dentro de cada função.

    (*) Nota do tradutor
    Isso é algo óbvio……bom, pelo menos deveria ser 🙂 .

  8. Uso de pré-processador deve ser limitado a inclusão de arquivos header e definição simples de macros. Macros complexas como as recursivas e com listas de argumentos variáveis, devem ser evitadas.

    (*) Nota do tradutor No texto original o autor descreve que o uso de macros de compilação condicional é algo dúbio entretanto não pode ser sempre ignorado. Eu concordo plenamente com a ideia de que não pode ser ignorado, uma vez que sempre tivemos diversas plataformas diferentes e dominantes na história da computação moderna, e o uso do pré-processador para se ter suporte a compilação condicional é uma excelente técnica que tem possibilitado manter um código portátil entre as diversas plataformas que vão desde os diversos sistemas operacionais disponíveis em PC’s até aos diversos dispositivos mobile existentes hoje.

  9. O uso de ponteiros deve ser restrito. Especificamente, não mais do que um nível de deferenciação é permitido. Operações de deferenciação de ponteiro não podem estar escondidas em macros ou dentro de declarações typedef. Ponteiros de função não são permitidos.

    (*) Nota do tradutor.
    Talvez esse seja o mais polêmico item do guia. Operações com ponteiros são algumas vezes complexas dependendo do nível de deferenciação. São raros os casos em que é necessário o uso de ponteiros duplos ou triplos, entretanto pode ser evitado e sugiro que seja evitado.
    Quanto ao uso de macros para deixar a deferenciação mais “limpa e clara”, para mim isso tem um nome e se chama “armadilha”. Fuja de quaisquer construções que “escondam” a complexidade de alguma operação, e essa regra não deve ser considerada apenas nas operações de ponteiros.
    Entretanto há ressalvas quanto ao uso de typedefs na declaração de um tipo ponteiro,  como por exemplo as definições de ponteiros para funções amplamente utilizadas nas API’s do Windows e UNIXes em geral, nesse caso não há como escapar uma vez que esses sistemas operacionais fazem uso extensivo de callbacks para proporcionar respostas a eventos requeridos e necessários para a aplicação do usuário.
    Quanto a proibição de ponteiros para função, talvez para a maioria das aplicações comuns de desktop seu uso realmente não seja necessário, entretanto para aplicações de missão crítica embarcadas como as que utilizam algum kernel real-time, como por exemplo o uC de Jean Labrosse e que fazem extenso uso de ponteiros para função para implementar as diversas tasks da aplicação do usuário, o uso de ponteiro de função é algo bem comum.
    A construção de softwares kernel real-time é repleta de ponteiros de função, até mesmo para proporcionar uma abstração de tasks, timers dentre outras estruturas típicas desse tipo de software.

  10. Todo código deve ser compilável desde o primeiro dia de desenvolvimento, com todos warnings do compilador ativados. Todo código deve compilar com essa configuração, sem gerar nenhum warning ou erro. Todo código deve ser checado diariamente com pelo menos um – de preferência mais do que um – excelente analisador de código estático (o que ele cita como analisador estado-da-arte), e a análise deve passar sem warning algum.

    (*) Nota do tradutor
    Quanto ao detalhe dos warnings de compilação, acredito que já seja bem comum em grandes projetos, entretanto a parte do analisador “estado-da-arte”, não creio que sequer mercados corporativos em países avançados a utilizem, exceto empresas de altíssima tecnologia que dependam de que seus softwares funcionem 24×7 ou de forma embarcada em algum dispositivo.

 Holzmann incluiu diversos comentários no documento original para cada uma das regras descritas acima, mas a essência do documento é que quando as regras forem utilizadas em conjunto, garantam um fluxo claro e transparente que tornem fácil a construção, testes e análise de código amplamente aceitos como livres de falhas. A JPL tem desenvolvido softwares automatizados para missões espaciais como a Mars Curiosity and a Voyager, e o laboratório já está usando essas regras em uma base experimental para escrever software de missão crítica.

Holzmann acredita que seguir as regras da NASA minuciosamente, pode diminuir a carga sobre os desenvolvedores e levar a uma melhor segurança e clareza do código.

“Se as regras parecerem draconianas no inicio, tenha em mente que elas foram criadas para que se possa checar códigos onde a sua vida pode depender muito de que haja precisão: código utilizado para controlar o avião em que você voa, a usina nuclear a poucas milhas de onde você vive, as aeronaves que carregam os astronautas em órbita”, escreve ele.

“As regras agem como o cinto de segurança em seu carro: Inicialmente eles parecem ser um pouco desconfortáveis, mas depois de um tempo seu uso se torna natural e não usá-los se torna inimaginável.”

O texto acima foi traduzido do original que pode encontrado no link do site SDTimes abaixo:

http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/

[]’s
PopolonY2k

Dennis Ritchie the father of everything

Since Dennis Ritchie passed away, I have been thinking to write something about this guy, not just because to me he is the most important computer scientist since early days of modern computer systems, but just because he was the father of everything we are running today.

The C programming language (Book cover)
The C programming language (Book cover)

Unfortunately the world did not give to him, what is in my opinion, the deserved attention in the moment of his death, because 7 days before another great entrepreneur had passed away, so the world media and market was more affected by his death. I’m talking about Steve Jobs, that is known as a great entrepreneur and business man, but without the work of Dennis Ritchie helping him indirectly, maybe his progression would have been more difficult than it was.

This is because all basic software of Apple, like MacOS X and IOS was written using the C language, created by Dennis Ritchie several years before at Bell Labs, and considering that both operating systems are UNIX-Like, the importance of Dennis Ritchie for Apple’s present day success increases, because he was the creator of UNIX too.

The Bell Labs.

It is impressive the influence of Dennis Ritchie in all modern languages, like, C#, Java, Shell scripting, and a lot of others that have their dialect based on C language, but when he created the C language I think that has was just thinking about reusing his works in new models of computers that were been born in the mid seventies.

In those days computer use was restricted to universities and big companies. Considering the corporate world I can say that this environment was a controlled place and it’s growth was maintained by other big companies like Hewlett Packard and IBM, but in university and the world of research this growth was more open and with no boundaries, I think that was almost chaotic.

At this time a well known research lab was the source of the biggest researches of the sixties and seventies, considering the computer science scene. This lab sponsored the development of a computer digital language whose main goal was to create a generic and abstract language capable to access the low level resources of any machine using a lightweight set of reserved commands, making it easier to learn than machine language.

I’m talking about the Bell Laboratories, a well known research institute at that time, created by another great genius and the father of all modern communication found today, Alexander Graham Bell. I remember in the early nineties I thought Bell Labs to be the most important place of technology since the sixties until those days and I was really fascinated by their creations, since C, UNIX and C++, all related to computer science, but if we consider the big legacy of Bell Laboratories, I must cite the transistor invention and the telephone, this one being the big start-up of Bell labs.

Dennis Ritchie and Ken Thompson at Bell Labs
Dennis Ritchie and Ken Thompson at Bell Labs

Maybe you know Bell Labs as AT&T, a big american telecommunication company from the eighties and nineties, but in fact AT&T is older than we know and the relationship with Bell labs came from the twenties and in my point of view, AT&T was a company behind the Institute Bell Labs, giving it financial support to develop the base of the current digital technology in the world.

Today Bell Labs is part of a French telecommunications company, known as Alcatel-Lucent and the good news about this is that the new company is keeping focus on technologies based on networking, software and other digital technologies. On the other hand other basic technologies like semiconductor research was taken apart.

The creation of the C language

 In the early nineties, I was very interested to learn about computer languages because I had started to study computer science in university and I was living a special moment where my colleagues and teachers were exchanging a lot of information about computer languages, mathematics, physics and other basic concepts.

In this motivating scenario where all seemed to be new, I was presented to the C language by several colleagues and specifically by a teacher, that was a student of the author of the well known best selling book Turbo C – The complete reference, Herbert Schildt.

The new edition of a classic - by Herbert Schildt.
C – The complete reference (Herbert Schildt)

Herbert Schildt was my first gate to the C language and after I started to learn just reading his books I wanted to learn about the creator of C language and why it was created, then the big question is why Dennis Ritchie created the C language ?

There are a lot of theories and tales about the motivation of the creation of the C language but in fact the real reason why Dennis Ritchie created the C language was because he was involved in UNIX development in conjunction with his big friend and colleague Ken Thompson, in the early seventies.

In those days, the UNIX operating system was barely beginning and it was completely written in assembly language for the DEC PDP-7 and it was known that PDP-7 was almost obsolete, then when the new DEC PDP-11 was released, the UNIX system would be dead too fast, because the compatibility between those machines was not so simple and natural as in modern computers.

UNIX (Thompson/Ritchie creation)
UNIX (Thompson/Ritchie creation)

The best choice was to look for a new, powerful and abstract language to use in his port of the UNIX operating system and the first choice of Ken Thompson was the B language, that is a variant of an older language, called BCPL.

Unfortunately B lacks a lot of features to help the programmers make good, abstract and scalable softwares.

Knowing all of these limitations Dennis Ritchie started to create the C language, based on some concepts of B language but without all of the features lacking of the B language.

After this, in the mid seventies the UNIX system was completely rewritten using the C language and until now UNIX and C, both, have been the most important technologies present on several modern computers and for overall learning in computer science too, thanks to Dennis Ritchie and Ken Thompson.

The legacy

Today we are living a great moment in the area of technology, a moment when new and exciting technologies are being born every day. But I think that we must never forget about these grand masters of computer science, that in the past created the strong base that we are using now and Dennis Ritchie is for me the most important of all computer scientists. Just because other great masters like Bjarne Stroustup, the father of C++, James Gosling, the father of Java and many other important guys, based their creations on Dennis Ritchie’s work.

C++ (Created by Bjarne Stroustrup)
C++ (Created by Bjarne Stroustrup)

I believe that Dennis Ritchie is directly and indirectly influencing all generations of new computer scientists and the IT professionals in general, because almost all commercial and open source technologies are based on his work.

Just to cite an example, today we have open technologies like Java and the other hand we have closed technologies like C#, these are two technologies that are now competing for attention from most professionals of the technology information market, but it is known that both share the same syntax and other features, and why not say, the same spirit of C language…….the spirit of Dennis Ritchie.

Ken Thompson and Dennis Ritchie
Ken Thompson and Dennis Ritchie

Enjoy the silence.

[]’s
PopolonY2k

References

Dennis Ritchie (Bell Labs page)
http://cm.bell-labs.com/who/dmr/

Dennis Ritchie death announcement (NY Times)
http://www.nytimes.com/2011/10/14/technology/dennis-ritchie-programming-trailblazer-dies-at-70.html?_r=0

Steve Jobs death announcement (TechCrunch)
http://techcrunch.com/2011/10/05/steve-jobs-has-passed-away/

Apple WebSite
http://www.apple.com

MacOSX (Wikipedia)
http://en.wikipedia.org/wiki/OS_X

IOS (Wikipedia)
http://en.wikipedia.org/wiki/IOS

The C language (Wikipedia)
http://en.wikipedia.org/wiki/C_(language)

Bell Labs (Alcatel website)
http://www3.alcatel-lucent.com/wps/portal/belllabs

UNIX
http://www.unix.org/

C# (Wikipedia)
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)

Java (Wikipedia)
http://en.wikipedia.org/wiki/Java_(programming_language)

Shell Script (Wikipedia)
http://en.wikipedia.org/wiki/Shell_script

Hewlett Packard
http://www.hp.com/

IBM
http://www.ibm.com

Alexander Grahan Bell (Wikipedia)
http://en.wikipedia.org/wiki/Alexander_Graham_Bell

C++ (Wikipedia)
http://en.wikipedia.org/wiki/C%2B%2B

AT&T
http://www.att.com/

Alcatel-Lucent
http://www.alcatel-lucent.com/

Turbo C – Complete reference (Amazon)
http://www.amazon.com/Turbo-Complete-Reference-Herbert-Schildt/dp/0078817765

Herbert Schildt
http://en.wikipedia.org/wiki/Herbert_Schildt

Ken Thompson’s bio at Bell Labs
http://www.bell-labs.com/history/unix/thompsonbio.html

DEC PDP-7
http://www.linfo.org/pdp-7.html

DEC PDP-11 (Wikipedia)
http://en.wikipedia.org/wiki/PDP-11

B Language (Wikipedia)
http://en.wikipedia.org/wiki/B_language

BCPL Language (Wikipedia)
http://en.wikipedia.org/wiki/BCPL

Bjarne Stroustrup
http://www.stroustrup.com/

James Gosling
http://nighthacks.com/roller/jag/