[ EN | PT ] The Rise and Fall of Zim DBMS
Zim is a DBMS that emerged around the 80s, following the entity-relationship model. With a language of the same name and a search syntax very similar to SQL, but with extended resources, the product dominated the Brazilian market between the late 1980s and early 1990s.
Characteristics
When you want to create a table, instead of using a command like CREATE TABLE my_table, you create an entity via the "data dictionary" (yes, it's confusing). The commands also have some differences from SQL, like changing SELECT to FIND. It is possible to create terminal-accessible programs in Zim as well, creating forms and screens via a data dictionary and opening them in the program (we'll talk about that a little later).
Programs were created using procedure (similar to a function, but without explicit return) and with "quirks" from other scripting languages of the time (such as Clipper and batch itself), although in a slightly different way. Local variables were created in the procedure definition (just like when you create a new Pascal program), and are weakly typed and dynamic. For creating arrays, however, it is necessary to create a global variable in the dictionary.
The advantages
An extremely simple and easy to learn programming language, it is possible to learn and start producing (in terms of programming) all the essential components of the language in less than a month. The commands are also simple (and mostly self-describing), having counterparts in (mostly) other languages. It is also possible to run system commands via Zim using the SYSTEM command as follows:
system "rm temp.txt"
In this way, it is possible to run external programs that have features that are impossible (or infeasible) to be implemented in Zim, such as converting CSV files to XLS.
The problems
Among the languages, Zim went against other banks, which started to use the SQL language as a standard (even with different dialects). In this way, it discouraged the creation of libraries to connect to different languages, since all their drivers were proprietary at the time. The company tried to fix this problem by adding support for SQL commands (except the data definition language) and creating their own drivers for some languages, such as Java.
The language was also an example of "do it all", serving both to create the system and user screens and to connect to databases. In the past, this was not seen in this way, but today this approach is considered problematic, as it encourages the insertion of business rule code on the system screens.
Another problem was the lack of features that were starting to become popular at the time. Some language features such as Regex, events, and procedural programming began to be lacking, and the difficult implementation of these features discouraged new systems built in Zim (as did the fact that, for a long time, the language was not 100% SQL-compatible). ). Its direct competitors in the 1980s were dBase, Clipper and TeraData, but by the 1990s Zim was already competing with databases that used the SQL language, such as Sybase, SQL Server and Postgres.
The community also did not adapt well to the internet age: while the SQL language was widely discussed and doubts were asked in forums, chans and communities, Zim was practically restricted to the corporate environment, where the sharing of data on more specific details was discouraged. of language. Its high price and the system not having a free version for developers or a clone ended up restricting access to the system even more, and although these problems were resolved, it was already too late.
The decay
The real downfall of Zim was precisely the reason for its rise in the beginning: its corporate advantages. Keeping an approach of "don't mess with a winning team", the company ended up making room for other alternatives, most of them free, within the corporate and educational environment, involving cost reduction and the adoption of the SQL standard for banks and other languages for building the application, such as Perl, C++, Delphi, and, more in the future, PHP and other web languages. Its unified and simple-to-use product was now just one of hundreds of alternatives that were emerging, it didn't have a community of independent programmers like SQL languages, it didn't have SQL language compatibility, simple actions like a backup were too laborious, and carrying out migrations was even more difficult.
The problem became even bigger when open source communities started to become popular: while the Postgres DBMS could have a bug on its system fixed in a matter of a few days by some random programmer around the world, Zim needed the company responsible knew about the bug and fixed it, and that could take months.
The lack of dissemination of the language outside the corporate environment also meant that there was a lack of new Zim professionals, and training a new professional was more expensive than just hiring a new employee of another language, which encouraged new projects to be carried out in competitors. of language.
In short, it was a language that has aged badly, and that has not managed to remain competitive in the midst of its more modern alternatives.
And today?
Zim DBMS is not dead. Although hardly new products and services are made using this system, the language continues to be constantly developed to ensure stability for legacy systems developed with it. They also developed a modern IDE, to provide existing developers with features like other IDE's on the market, and regular bug fixes to maintain system security and stability.
Is that you? Do you know any early computing tools with a similar story?
Zim é um SGBD que surgiu próximo a década de 80, seguindo o modelo entidade-relacionamento. Com uma linguagem de mesmo nome e com uma sintaxe de busca muito semelhante ao SQL, porém com recursos estendidos, o produto dominou o mercado brasileiro entre o fim dos anos 80 e início dos anos 90.
Características
Quando você deseja criar uma tabela, ao invés de usar um comando como CREATE TABLE minha_tabela, você cria uma entidade através do "dicionário de dados" (sim, é confuso). Os comandos também possuem algumas diferenças em relação ao SQL, como mudar o SELECT por FIND. É possível criar programas acessíveis via terminal no Zim também, criando os formulários e telas via dicionário de dados e os abrindo no programa (vamos falar disso um pouquinho mais pra frente).
Os programas eram criados usando procedure (semelhante a uma função, porém sem possuir retorno explícito) e com "peculiaridades" de outras linguagens de script da época (como Clipper e o próprio batch), embora de forma um pouco diferente. As variáveis locais eram criadas na definição da procedure (assim como quando você cria um novo programa em Pascal), e tem tipagem fraca e dinâmica. Para a criação de arrays, no entanto, é necessário criar uma variável global no dicionário.
As vantagens
Uma linguagem de programação extremamente simples e fácil de ser aprendida, é possível aprender e começar a produzir (em termos de programação) em menos de um mês todos os componentes essenciais da linguagem. Os comandos também são simples (e, em sua maioria, autodescritivos), tendo correspondentes em outras linguagens (na maioria). Também é possível executar comandos do sistema via Zim usando o comando SYSTEM da seguinte forma:
system "rm temp.txt"
Dessa forma, é possível executar programas externos que possuam recursos que são impossíveis (ou inviáveis) de serem implementados em Zim, como converter arquivos CSV para XLS.
Os problemas
Entre as linguagens, o Zim ia na contramão de outros bancos, que passaram a usar a linguagem SQL como padrão (mesmo com dialetos diferentes). Dessa forma, desincentivava a criação de bibliotecas para conexão com diferentes linguagens, fora que todos os seus drivers eram proprietários na época. A empresa tentou corrigir esse problema, adicionando suporte a comandos SQL (exceto a linguagem de definição de dados) e criando seus próprios drivers para algumas linguagens, como Java.
A linguagem também era um exemplo de "faz tudo", servindo tanto para criar o sistema e telas para usuário quanto para conectar a bancos de dados. Antigamente isso não era visto dessa forma, mas hoje se considera problemática essa abordagem, pois incentiva a inserção de código de regra de negócio nas telas do sistema.
Outro problema era a falta de recursos que começavam a se tornar populares na época. Alguns recursos de linguagem, como Regex, eventos e programação procedural começaram a fazer falta, e a difícil implementação desses recursos desencorajava novos sistemas criados em Zim (assim como o fato de, por muito tempo, a linguagem não ter sido 100% compatível com SQL). Seus concorrentes diretos na década de 80 eram o dBase, o Clipper e o TeraData, mas, na década de 90, o Zim já concorria com bancos que usavam a linguagem SQL, como o Sybase, o SQL Server e o Postgres.
A comunidade também não se adaptou bem a era da internet: enquanto a linguagem SQL era amplamente discutida e dúvidas eram tiradas em fóruns, chans e comunidades, o Zim estava praticamente restrito ao ambiente corporativo, onde era desincentivado o compartilhamento de dados sobre detalhes mais específicos da linguagem. Seu preço alto e o sistema não ter uma versão gratuita para desenvolvedores ou um clone acabava restringindo ainda mais o acesso ao sistema, e, embora esses problemas terem sido resolvidos, já era tarde demais.
A decadência
A queda real do Zim foi justamente o motivo de sua ascensão no início: suas vantagens corporativas. Mantendo uma abordagem de "não mexer em time que está ganhando", a empresa acabou abrindo espaço para outras alternativas, grande parte até gratuitas, dentro do ambiente corporativo e educacional, envolvendo redução de custos e adoção do padrão SQL para bancos e de outras linguagens para a construção da aplicação, como o Perl, o C++, o Delphi, e, mais futuramente, o PHP e outras linguagens web. Seu produto unificado e simples de se usar agora era apenas mais um entre centenas de alternativas que estavam surgindo, não possuía uma comunidade de programadores independentes como as linguagens SQL, não possuía compatibilidade com a linguagem SQL, ações simples, como um backup, eram muito trabalhosas, e realizar migrações era ainda mais difícil.
O problema se tornou ainda maior quando as comunidades open source começaram a se tornarem populares: enquanto o SGBD Postgres poderia ter um bug em seu sistema resolvido em questão de poucos dias por algum programador aleatório ao redor do mundo, o Zim precisava que a empresa responsável soubesse da existência do bug e o corrigisse, e isso poderia levar meses.
A falta de divulgação da linguagem fora do ambiente corporativo também fez com que houvesse uma ausência de novos profissionais Zim, e treinar um novo profissional era mais caro que apenas contratar um funcionário novo de outra linguagem, o que incentivava que novos projetos fossem feitos nos concorrentes da linguagem.
Em resumo, foi uma linguagem que envelheceu mal, e que não conseguiu se manter competitiva no meio de suas alternativas mais modernas.
E hoje?
O Zim SGBD não morreu. Embora dificilmente novos produtos e serviços sejam feitos usando esse sistema, a linguagem continua em constante desenvolvimento para garantir estabilidade para os sistemas legados desenvolvidos com ela. Também desenvolveram uma IDE moderna, para garantir aos desenvolvedores existentes recursos como os de outras IDE's do mercado, e correções regulares de bugs para manter a segurança e estabilidade do sistema.
E você? Conhece alguma ferramenta dos primórdios da computação com uma história parecida?