5 ms·

It's cheap to portray COBOL programmers as cowboys, but COBOL and the ecosystem around it is actually one of the most organized and fit-for-purpose programming

It's cheap to portray COBOL programmers as cowboys, but COBOL and the ecosystem around it is actually one of the most organized and fit-for-purpose programming languages around even if it isn't modern by any means. Time will tell if banks and insurances will fare better with J2EE-based systems (meaning classic Java-based enterprise stacks such as EJBs and portlets running under shudder Websfear, which count as new-fangled compared to COBOL in these circles). I could imagine classic J2EE maintenance is being neglected as career path for millenials, just as COBOL is/was for the generation before. J2EE exposes much more escape hatches into system programming and rope to hang yourself, and at the same time will be around for a long time to come, since Java has been the go-to language for almost all big-time eCommerce and FinTech projects at banks/insurances since 2000. Edit: a-ok, "cowboys" is part of name of that guy's consulting business

wiz21c 8y ago
I don't know for COBOL, but for JEE, we've been able to migrate out of weblogic (to jboss) and then from oracle to postgresql (on code which is 10 years old). So even if JEE might be hard to maintain, it allows some flexibility in the base tools you choose. (my view of COBOL is that once you're into a vendor, it's pretty hard to leave to another one because COBOL is close to the metal, I may be totally wrong) but in the long run, the problem is also the business logic. What disappears is the knowledge of the hacks that were applied at the business logic level. And this is much harder than to recover from the code. So I guess one has to make the difference between business logic maintenance and the actual COBOL maintenance. But having rewrote some huge COBOL app in Java, I can say that Java is better structured, at a framework complexity cost.
- repolfx 8y ago
  Better structured, easier to debug, and the tooling exists to incrementally refactor in a relatively safe way. There are also migration paths to better worlds. IntelliJ can auto-rewrite Java into Kotlin, preserving comments and formatting along the way, and even detecting common Java idioms that have better Kotlin equivalents and rewriting them too. So, not only can you migrate to better app containers, database engines, upgrade your garbage collector and compilers etc, but also even switch to a much more modern language nearly pain free.
  - tcbawo 8y ago
    Regardless of whether Kotlin is considered a better world than Java, I'm skeptical that this sort of automatic translation adds significant value.
    - einarfd 8y ago
      I've been using Intellij's Java to Kotlin conversion a bit lately, and the code it spits out is fairly decent Kotlin, and with a pass through on nullability and switching out Java types with native Kotlin types afterwards. It gets just as good as it would get if I hand translated my self, but it takes a lot less time. I suspect that part of the reason that this works well, is that Java and Kotlin isn't that dissimilar. Doing automated conversion between Java and Scheme for example, would be a lot harder to get right.
- anon49124 8y ago
  Hard-coded business logic: yuck. IIRC there's proprietary software (SDKs / integrations) specifically for specifying, running, testing and enforcing business rules efficiently so that applications just present an API or respond to events rather than having to know everything about the business, and so not having to change N apps when a business rule changes / track down weird bugs when a business rule changes because another system didn't get a change also.
  - adrianN 8y ago
    Some people prefer to "hardcode" business logic in Java instead of hardcoding it in XML or whatever business logic specification language the proprietary tools use. At least you can hire Java programmers fairly cheaply.
    - mrweasel 8y ago
      I would pick hardcoding for most projects. You often end up creating a new DSL for your business logic, but because most of us aren’t language designers our DSLs end up being worse than what ever language the project is written in. Almost every time you will fail to correctly anticipate the future needs and your DSL won’t be sufficient anyway.
  - ro_sharp 8y ago
    The code is only hard if you can't release it safely.
  - wiz21c 8y ago
    That quite deepnds on the business. Some of our data scenario are super complex (thousands of datapoints, where one influence the others depending on how they happen in time, depending on manual intervention, things that happen here and there). Because of that, the usual tools to write your business logic fall short on the testing part. They're good at writing/maintaining simple rules, versioning them, but when a time dimension is crucial, then well, it's not that good anymore.
- C1sc0cat 8y ago
  TSB's migration from legacy to Java based was a complete omnishambles.
  - 3rdAccount 8y ago
    There were many HN articles on that...was it last year?
anon49124 8y ago
Yes, they're definitely from Texas: not the usual "cowboy coders" == "coders whom take too much initiative / don't follow a plan / directions." J2EE usually means GC pauses (hell), XML (hell again) and dependency injection (hell also). Thankfully, hells tend to pay well if someone is willing to schlep the muck around quickly and reliably. JVM (IBM's, Oracle's) and CLR runtimes are battle-tested and much more widely deployed to run civilization than most non-enterprise developers realize. Also, I should probably look that guy up as I'm in North Texas at the moment.
- vbsteven 8y ago
  Can you explain why you describe dependency injection as "hell"? I prefer working with DI/IoC rather than without it.
  - thisone 8y ago
    Heh, not the op but I'll bite. I just had to go through an open source project that uses guice, in order to try to trace a particular code path, since the user group was less than helpful. Trying to figure what was running was an absolute nightmare of nested magic spread out through a score of files. Meaning as soon as I had a clue, I'd lose it as I had to retrace back through all those files. I'm sure it's clear as crystal to the people who wrote it, but DI can be obtuse as hell if you have to figure what's actually running on your own.
    - spatulon 8y ago
      I understand dependency injection to mean 'pass dependencies as arguments', which seems pretty simple and reasonable. e.g. instead of void foo() { SingletonLogger::logError("no cheese"); } you'd write void foo(ILogger logger) { logger.logError("no cheese"); } Now it's much easier to unit test `foo` with a mock logger object. Is there more to it than that? Why are there big, complicated frameworks for it?
      - thisone 8y ago
EADGBE 8y ago
Oh how I loathe WebSphere.

wiz21c 8y ago

I don't know for COBOL, but for JEE, we've been able to migrate out of weblogic (to jboss) and then from oracle to postgresql (on code which is 10 years old). So even if JEE might be hard to maintain, it allows some flexibility in the base tools you choose. (my view of COBOL is that once you're into a vendor, it's pretty hard to leave to another one because COBOL is close to the metal, I may be totally wrong) but in the long run, the problem is also the business logic. What disappears is the knowledge of the hacks that were applied at the business logic level. And this is much harder than to recover from the code. So I guess one has to make the difference between business logic maintenance and the actual COBOL maintenance. But having rewrote some huge COBOL app in Java, I can say that Java is better structured, at a framework complexity cost.

repolfx 8y ago
Better structured, easier to debug, and the tooling exists to incrementally refactor in a relatively safe way. There are also migration paths to better worlds. IntelliJ can auto-rewrite Java into Kotlin, preserving comments and formatting along the way, and even detecting common Java idioms that have better Kotlin equivalents and rewriting them too. So, not only can you migrate to better app containers, database engines, upgrade your garbage collector and compilers etc, but also even switch to a much more modern language nearly pain free.
- tcbawo 8y ago
  Regardless of whether Kotlin is considered a better world than Java, I'm skeptical that this sort of automatic translation adds significant value.
  - einarfd 8y ago
    I've been using Intellij's Java to Kotlin conversion a bit lately, and the code it spits out is fairly decent Kotlin, and with a pass through on nullability and switching out Java types with native Kotlin types afterwards. It gets just as good as it would get if I hand translated my self, but it takes a lot less time. I suspect that part of the reason that this works well, is that Java and Kotlin isn't that dissimilar. Doing automated conversion between Java and Scheme for example, would be a lot harder to get right.
anon49124 8y ago
Hard-coded business logic: yuck. IIRC there's proprietary software (SDKs / integrations) specifically for specifying, running, testing and enforcing business rules efficiently so that applications just present an API or respond to events rather than having to know everything about the business, and so not having to change N apps when a business rule changes / track down weird bugs when a business rule changes because another system didn't get a change also.
- adrianN 8y ago
  Some people prefer to "hardcode" business logic in Java instead of hardcoding it in XML or whatever business logic specification language the proprietary tools use. At least you can hire Java programmers fairly cheaply.
  - mrweasel 8y ago
    I would pick hardcoding for most projects. You often end up creating a new DSL for your business logic, but because most of us aren’t language designers our DSLs end up being worse than what ever language the project is written in. Almost every time you will fail to correctly anticipate the future needs and your DSL won’t be sufficient anyway.
- ro_sharp 8y ago
  The code is only hard if you can't release it safely.
- wiz21c 8y ago
  That quite deepnds on the business. Some of our data scenario are super complex (thousands of datapoints, where one influence the others depending on how they happen in time, depending on manual intervention, things that happen here and there). Because of that, the usual tools to write your business logic fall short on the testing part. They're good at writing/maintaining simple rules, versioning them, but when a time dimension is crucial, then well, it's not that good anymore.
C1sc0cat 8y ago
TSB's migration from legacy to Java based was a complete omnishambles.
- 3rdAccount 8y ago
  There were many HN articles on that...was it last year?

anon49124 8y ago

Yes, they're definitely from Texas: not the usual "cowboy coders" == "coders whom take too much initiative / don't follow a plan / directions." J2EE usually means GC pauses (hell), XML (hell again) and dependency injection (hell also). Thankfully, hells tend to pay well if someone is willing to schlep the muck around quickly and reliably. JVM (IBM's, Oracle's) and CLR runtimes are battle-tested and much more widely deployed to run civilization than most non-enterprise developers realize. Also, I should probably look that guy up as I'm in North Texas at the moment.

vbsteven 8y ago
Can you explain why you describe dependency injection as "hell"? I prefer working with DI/IoC rather than without it.
- thisone 8y ago
  Heh, not the op but I'll bite. I just had to go through an open source project that uses guice, in order to try to trace a particular code path, since the user group was less than helpful. Trying to figure what was running was an absolute nightmare of nested magic spread out through a score of files. Meaning as soon as I had a clue, I'd lose it as I had to retrace back through all those files. I'm sure it's clear as crystal to the people who wrote it, but DI can be obtuse as hell if you have to figure what's actually running on your own.
  - spatulon 8y ago
    I understand dependency injection to mean 'pass dependencies as arguments', which seems pretty simple and reasonable. e.g. instead of void foo() { SingletonLogger::logError("no cheese"); } you'd write void foo(ILogger logger) { logger.logError("no cheese"); } Now it's much easier to unit test `foo` with a mock logger object. Is there more to it than that? Why are there big, complicated frameworks for it?
    - thisone 8y ago

EADGBE 8y ago

Oh how I loathe WebSphere.