Tuesday, May 25, 2021

Programming in the 18th Century

Are we cutting the trees down with axes or two-man saws? Are we removing the bark with a draw knife? Are we making a log house to minimize our effort? Are we making lumber from a water-powered sawmill? Are we using a solid 12-inch iron hammer? Are we using iron nails?


These are all of the questions I have been answering for some 40 years of developing software in the multi-value world with our piss poor toolset and lack of quality tool vendors.


To refresh your memory a little about multi-value tools here we go. Using AE/ED line by line editor that one of my clients likened the editor to DOS Edlin. My personal favorite is using the editor ED in D3 and forgetting to flip the buffer so the changes did not take. Using UniQuery/RetrieVe syntax at a telnet prompt and my client thought I was using a variation of SQL. I was unable to add a logo to a bunch of forms in UniBasic, but I was proud that I could get it to print out on a laser printer on their network and the client was not impressed.


Our current database vendor has not bought any tools from vendors in quite some time but believes that they can create them from scratch. Their Visual Studio editor is half-baked, cannot compile code, and is missing the majority of features that no other tools vendor would get away with saying wait for the next release. Their front-end developer tool allows you to expose RESTful services to whatever framework you use to replace your telnet framework.


The problem is that most of the programmers using multi-value are over 40 years if not 60 years old. After you get over 40 years old you don't want to learn a new framework let alone these new-fangled tools built by database engineers that have not coded an application ever. Moreover, those programmers work for companies that have milked the multi-value technology for years and think why should I spend money where they cannot see an ROI.


I started developing tools 20 years ago at U2logic that some of my employees and the corporate staff were a mistake. They were somewhat right. The tools: database Editor, database software installer, database web developer, database resizer, database report writer, and database middleware were never a commercial success. However, what they did allow was a small company to develop web-based software that was innovative, pretty, functional, and damn near bug-free.


Our clients say can I have this report with these columns, these break-points, and with this heading with of course a logo. Using open-source BIRT running under Eclipse IDE with our database hookup, that report can be produced anywhere from minutes to days instead of weeks as before. And should the clients want the report in PDF, XLXS, DOCX, or HTML format, we write it once and BIRT uses emitters to produce those requested outputs.


Using Eclipse IDE running our UniBasic editor, a program can be changed and compiled in seconds without knowing how to FTP or what network drive we need to move the source code to. Our XLr8Editor allows you to see your compiler errors as you type which makes debugging the code much faster than the current solutions offered by our database vendor. Since all of the UniBasic code is indexed you can what routines you have already written that might accomplish this task without consulting an external document.


I could go on but you should see the point: Let's move out of our the 18th Century mindset with tools for our present day, or we do not and hope our programmers never die or retire. Either way, one of us will be coding faster, prettier, bug-free, using web interfaces, and have happy clients while the other is still flipping the frigging buffer.