3 ms·

> Compare use case to use case, not language to language. Then you are comparing "bank account interest and debt systems" to "embedded drivers". Or "tax syste

> Compare use case to use case, not language to language. Then you are comparing "bank account interest and debt systems" to "embedded drivers". Or "tax systems" to "embedded drivers". Or "insurance policy engines" to "embedded drivers", etc. COBOL is not a use-case, and all of the above could be done in any language. If we are discussing the qualities, ease of training , workforce availability and overall viability of COBOL, it is against the qualities, ease of training, workforce availability and overall viability of other languages. > We can train up COBOL developers MORE easily than embedded driver devs. And we can train up web devs more easily than embedded driver devs. Your argument makes no sense, as it is a false dichotomy. It also entirely misses the point that I stated earlier, that a company does not want to be able to train developers, they already trained developers to be in abundance in the market. > I've know embedded driver developers and y you're completely wrong I work in embedded (nowadays audio and display tech), and with driver development (to make said embedded devices useful, previously for high performance datacenter network equipment), and you're completely wrong. Not to mention delusional regarding COBOL to the point of being a suspect of IBM employment. The only still relevant quality of COBOL is that it does not self combust so we can take our time with replacing it with something contemporary and financially sensible.

_DeadFred_ 2y ago
You're not really contradicting me you're actually underlining what I was getting at. You claimed the COBOL ecosystem is too small to depend on. I pointed out that the embedded driver ecosystem is similarly small, yet we rely on it all the time. That’s a valid comparison as both involve small pools of specialists, niche tooling, long lived systems, and a steep learning curve. When I say “ecosystem,” that’s what I mean, not “tax systems” or “insurance policy engines,” which aren’t standalone developer ecosystems in the same way. Equating those with actual engineering ecosystems like COBOL or embedded drivers doesn’t really hold up. Since you say you work in embedded then you should be well aware that embedded driver developers form a highly specialized subset, often with deep platform specific expertise and niche tooling. It is, in fact, easier to train a developer to work on enterprise COBOL systems than to become effective in low-level driver development. That’s not controversial it’s backed by experience across industries. As for suggesting I must work for IBM because I don’t agree with your framing that’s not a serious argument. It’s not grounded in facts or reason, and doesn’t contribute anything meaningful to the discussion. If you’re interested in debating the actual points, I’m happy to continue. If not, I’ll leave it here.

_DeadFred_ 2y ago

You're not really contradicting me you're actually underlining what I was getting at. You claimed the COBOL ecosystem is too small to depend on. I pointed out that the embedded driver ecosystem is similarly small, yet we rely on it all the time. That’s a valid comparison as both involve small pools of specialists, niche tooling, long lived systems, and a steep learning curve. When I say “ecosystem,” that’s what I mean, not “tax systems” or “insurance policy engines,” which aren’t standalone developer ecosystems in the same way. Equating those with actual engineering ecosystems like COBOL or embedded drivers doesn’t really hold up. Since you say you work in embedded then you should be well aware that embedded driver developers form a highly specialized subset, often with deep platform specific expertise and niche tooling. It is, in fact, easier to train a developer to work on enterprise COBOL systems than to become effective in low-level driver development. That’s not controversial it’s backed by experience across industries. As for suggesting I must work for IBM because I don’t agree with your framing that’s not a serious argument. It’s not grounded in facts or reason, and doesn’t contribute anything meaningful to the discussion. If you’re interested in debating the actual points, I’m happy to continue. If not, I’ll leave it here.