3 ms·

For all of these large, old organisations that still use COBOL, the risk isn’t that they run out of COBOL engineers to hire. COBOL is a very simple programming

For all of these large, old organisations that still use COBOL, the risk isn’t that they run out of COBOL engineers to hire. COBOL is a very simple programming language, it was designed to be as simple as SQL. SQL was designed to be so easy that non-programmer business analysts could use it, COBOL was designed to be the same thing, but for non-DB business logic. Though you could debate how successful either of them were. The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.

throw_m239339 7y ago
The irony for me is that SQL is the language that stood up the test of time the most. All other are/were gamble. Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration. > The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk. In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.
- scarface74 7y ago
  I actively avoid companies that put all of their logic in the DB. It’s harder to version control, harder to unit test, much more work to rollback. You can’t keep it in sync with the source code etc. I can’t just switch branches and know the state of the system at the time the branch was created.
  - throw_m239339 7y ago
    You're making good points. First, I'm talking about a PL "middleware" layer than does not necessarily involves restructuring the data itself (basically, instead of querying tables or views, you query stored procedures or functions). When it comes to version control, wouldn't a migration system suffice to assess the state of that layer? As for unit testing, I kind of agree, it's possible though, like any other programming language.
    - scarface74 7y ago
      That doesn’t help. You can’t imagine the times I see Get_Customer_1 Get_Customer_2 Get_Customer_3 As far as version control, if someone does make a change to the unversioned “Get_Customer” and I want to switch branches. How do I make sure all of the stored procedures are in sync?
      - AmericanChopper 7y ago
        This is pretty much my experience with stored proc codebases too. I do consider SQL to be a very simple language, but store proc codebases tend to become incredibly complex. Finding an engineer that can maintain SQL code is very easy. Finding one that can maintain a particular maze of 1000+ stored procedures, views, functions, table triggers... is a completely different question.

throw_m239339 7y ago

The irony for me is that SQL is the language that stood up the test of time the most. All other are/were gamble. Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration. > The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk. In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.

scarface74 7y ago
I actively avoid companies that put all of their logic in the DB. It’s harder to version control, harder to unit test, much more work to rollback. You can’t keep it in sync with the source code etc. I can’t just switch branches and know the state of the system at the time the branch was created.
- throw_m239339 7y ago
  You're making good points. First, I'm talking about a PL "middleware" layer than does not necessarily involves restructuring the data itself (basically, instead of querying tables or views, you query stored procedures or functions). When it comes to version control, wouldn't a migration system suffice to assess the state of that layer? As for unit testing, I kind of agree, it's possible though, like any other programming language.
  - scarface74 7y ago
    That doesn’t help. You can’t imagine the times I see Get_Customer_1 Get_Customer_2 Get_Customer_3 As far as version control, if someone does make a change to the unversioned “Get_Customer” and I want to switch branches. How do I make sure all of the stored procedures are in sync?
    - AmericanChopper 7y ago
      This is pretty much my experience with stored proc codebases too. I do consider SQL to be a very simple language, but store proc codebases tend to become incredibly complex. Finding an engineer that can maintain SQL code is very easy. Finding one that can maintain a particular maze of 1000+ stored procedures, views, functions, table triggers... is a completely different question.