4 ms·

The quality of IT reporting continues to disappoint. The idea of no-code/low-code is to lower barriers to entry. This is a process that started with the invent

by rsj_hn 4y ago

The quality of IT reporting continues to disappoint. The idea of no-code/low-code is to lower barriers to entry. This is a process that started with the invention of C, continued with the much-despised COBOL, and had perhaps its greatest success with Microsoft Visual Basic macros. Yes, professional developers complained about the quality of that code, but it was a boon for many offices and was wildly popular. The idea is to make programming available to more and more people, so that with macros even secretaries could automate some Windows office tasks without needing to learn C++. This is just a continuation of that process of trying to lower the entry bar for deploying automation. You are not going to write an auto-safety feature or build a load balancer using these technologies, but you are going to allow someone on the margins to automate a data entry process or put together a simple series of webviews. However if you provide someone with a new tool to take on a new role, that isn't going to solve the problem of the person being too busy with all their existing roles. That's a completely different problem. Of course low-code isn't a cure for someone being overworked. It's meant to help someone with a lower skill level take on new work.

zozbot234 4y ago
Not sure if serious... COBOL was one of the earliest 3rd gen programming languages. Back then no one had a clue what high-level programming would ultimately look like, so "make it read kinda like English" was a nice first try at the problem. (There were also highly pragmatic reasons behind that, such as the paucity of common symbols in the non-standard character sets that were used back then. This shows up in other early languages, but nowhere so clearly as in COBOL.) Nowadays we know that the "low code" paradigm does not help beyond absolutely trivial examples. In particular it does not make the resulting artifacts easier to audit or survey, rather the opposite.
- rsj_hn 4y ago
  Not sure if you read my post, but yes I used COBOL as an example of a high level language because it was one of the first attempts. That is what the phrase "long line" refers to. A historical look back at the earliest attempts to do this. Also, the idea of lowering the bar does not mean you spend 50 years on doing the same thing over and over again. This is also the point I made. First, they dropped the requirement to program in Assembly and created higher level languages such as C or COBOL. Then they dropped the requirement of having a separate toolchain/build infrastructure and created VisualBasic. It is quite foolish to think that VisualBasic was popular because of its syntax. VisualBasic was popular because the developer environment/runtime were bundled into the office suite. Programs were extremely portable and the runtime was everywhere. It is the same reason that javascript became popular. That got rid of a lot of infrastructure and lowered the entry bar. It was the macro feature that made it a success, not the syntax. Then comes the no-code toolkits which have drag and drop and other features which you can get really distracted by, but they really work on the basis of a fixed set of libraries and a fixed set of calling conventions that is intended to simplify the chores of library selection and invocation. Again, the point is to remove or simplify something by automatically providing it. How much of a success it is will depend on how good it is at removing complexity for the set of tasks it is designed to tackle, which will ultimately be decided by market adoption. But one thing these tools cannot do, is free up people who are already busy. What they can do is lower the entry bar so people who wouldn't be productive because the barriers to entry are too high can be productive at rolling out simple automation tasks. The Marketing exec rolling out some clumsy dashboard reporting tool via a no-code process is the natural evolution of the secretary creating a form with visualbasic, which is itself the natural evolution of an accountant writing a script that calculates a depreciation schedule with COBOL.

by rsj_hn 4y ago

zozbot234 4y ago

Not sure if serious... COBOL was one of the earliest 3rd gen programming languages. Back then no one had a clue what high-level programming would ultimately look like, so "make it read kinda like English" was a nice first try at the problem. (There were also highly pragmatic reasons behind that, such as the paucity of common symbols in the non-standard character sets that were used back then. This shows up in other early languages, but nowhere so clearly as in COBOL.) Nowadays we know that the "low code" paradigm does not help beyond absolutely trivial examples. In particular it does not make the resulting artifacts easier to audit or survey, rather the opposite.

rsj_hn 4y ago
Not sure if you read my post, but yes I used COBOL as an example of a high level language because it was one of the first attempts. That is what the phrase "long line" refers to. A historical look back at the earliest attempts to do this. Also, the idea of lowering the bar does not mean you spend 50 years on doing the same thing over and over again. This is also the point I made. First, they dropped the requirement to program in Assembly and created higher level languages such as C or COBOL. Then they dropped the requirement of having a separate toolchain/build infrastructure and created VisualBasic. It is quite foolish to think that VisualBasic was popular because of its syntax. VisualBasic was popular because the developer environment/runtime were bundled into the office suite. Programs were extremely portable and the runtime was everywhere. It is the same reason that javascript became popular. That got rid of a lot of infrastructure and lowered the entry bar. It was the macro feature that made it a success, not the syntax. Then comes the no-code toolkits which have drag and drop and other features which you can get really distracted by, but they really work on the basis of a fixed set of libraries and a fixed set of calling conventions that is intended to simplify the chores of library selection and invocation. Again, the point is to remove or simplify something by automatically providing it. How much of a success it is will depend on how good it is at removing complexity for the set of tasks it is designed to tackle, which will ultimately be decided by market adoption. But one thing these tools cannot do, is free up people who are already busy. What they can do is lower the entry bar so people who wouldn't be productive because the barriers to entry are too high can be productive at rolling out simple automation tasks. The Marketing exec rolling out some clumsy dashboard reporting tool via a no-code process is the natural evolution of the secretary creating a form with visualbasic, which is itself the natural evolution of an accountant writing a script that calculates a depreciation schedule with COBOL.