The infamous Brazilian IT market protection that lasted from 1978 to 1992 had an amusing side-effect: exposed a generation of IT people (oldies like me that are approaching 40) to a technology fast-forward. I began to work with computers in 1990 and had contact with platforms that belong to the end of 1970's, if we consider the USA market as the "standard timeline".
So, in a sense, I could say I have 30 or 35 years of "experience" -- for the good and for the bad. In my case, there is an additional twist: I was an ERP programmer until 1999, and turned to low-level development ever since.
Not much people I know did this transition. Most friends I made in ERP era still work with ERP and we hardly talk about computers in social meetings. Even our lifestyles have diverged.
For example, I have a friend, Emanoel, that wrote a complete MRP system before reaching 20, and still does this kind of thing. He didn't have a computer at home until not long ago. And he only bought one in order to download movies and games.
Strange people that does not have at least a couple computers at home, and does not hack for the sake of hacking...
I and Emanoel worked together in a software house back at 1993. Being a developer at that time, in this region of Brazil, meant developing ERP systems using some kind of fourth-generation language. There were a number of vertical products that bundled together a database with a "4GL" language: Progress, Zim, Informix, Dataflex, Mumps, Accel/Unify, etc. (In the other hand, good 4GL products like PowerBuilder are not bundled with a database.) There was a big rivalry between developer guilds, each one defending the tool/language he/she worked with.
Why every software house chose a different 4GL? Probably because the ERP clients needed to buy 4GL runtime licenses. So, the 4GL salesmen approached a software house and offered the product for free, including training and support, in order to make the market. (I remember that many clients didn't want to pay for the licenses, so we have to duplicate carefully the license diskettes, so they could be reused in different sites. The licenses limited the maximum simultaneous users of a database, which caused a steady stream of calls to our support.)
Me and Emanoel worked with ZIM. It is so obscure that not even Wikipedia has an entry for it. But it was more or less like the other 4GLs at that time. 4GLs have a gentle learning curve, easy to develop database-related things, and easy to debug. But any task that does not fall in this category becomes very difficult to solve. I call this the "4GL brickwall".
For example, in order to generate any kind of file, like a CSV data export file, we had to use the ZIM report features. There was no file-handling functions in ZIM. The report was the only loophole that an application could use to specify an arbitrary file name. But the data format had to be carefully specified as if it were a print report... it did not allow the output of binary data. Tasks like that were actually easier to code in C than in ZIM (sometimes I did some tasks in C first, to "prototype" the desired result).
In 1999 that business was still using Zim, and I was hired to develop an e-commerce gateway, that is, some kludge to allow a Web application to communicate with a Zim database. It was certainly the ugliest thing I did in my life. Since Zim supported a prompt mode, each Web session spawned a new Zim prompt. My gateway translated CGI requests to SQL-like queries fed to the Zim prompt via pseudo-terminal, and the result was translated back to HTML.
Amazingly, that thing worked. Even worse was the MS-DOS version of the kludge. In the absense of pseudo-terminals, the only solution left was to "post" a file in a folder, and each ZIM session ran an agent that read that folder once a second. If there was a file, it was picked up, interpreted, processed, and result was posted as another file.
ZIM was a nightmare when there were too many concurrent users, because of database page locking and absense of some mechanism like MVCC. Without MVCC, even read transactions will lock. To be fair, even 'modern' databases like MS-SQL had this kind of problem until the early 2000s... The "solution" to the concurrency problems was to fiddle with some "magic" tuning parameters, which sometimes eased problems in one component but created problems in another.
Another "solution" we often adopted to solve such problems was to break a transaction in several smaller parts, or sometimes not using transactions at all (since every ZIM database command was a transaction by itself). This was very bad -- if the process was aborted, the transaction would be half done -- but it was better to take this risk than halting the whole ERP because the accounting department decided to print a balance sheet.
Most 4GL databases had a big advantage over solutions like CA-Clipper: they were portable. I worked with Zim in several platforms: HP/UX, AIX, 386/ix, MS-DOS, Edisa (a Brazilian minicomputer that ran a homebrew version of UNIX). That's how I came in contact with UNIX, which probably set my fate to work with Linux :)
The fatal blow to ZIM was the popularization of Windows. There was a Zim for Windows, but it was pathetic. That ERP house had to decide between Java, Visual Basic or Delphi, and ended up rewriting the system in Delphi. Interestingly, CA-Clipper was "killed" by the same process: failure to provide a migraiton path to Windows.
I feel sorry for the people that worked hard migration ERP systems from whatever text-based platform to Windows, because two or three years later the new fad was the Web-based application.
