3 ms·

Where in the world did you get those statistics from?

_DeadFred_ 2y ago
IBM puts the number of COBOL devs at around 2 million, others around 1 million. Full-time experienced people is placed at around 200,000. Total embedded devs are around 2-2.5 million, but embedded driver devs are a much smaller subset. Hard to find numbers but probably around again 200,000 full time experienced so roughly the same amount.
- arghwhat 2y ago
  So numbers from the only supplier...? You are making a false comparison. Even if we assume the number is correct, you're making a false comparison - COBOL is a language, "embedded drivers" is a software component. The equivalent to your COBOL number is all C/C++ developers. Looking at some random online statistics like you did, COBOL is at 0.7% usage in 2024 vs. 20.3% for C and 23% for C++. Is that statistic credible? No, but neither is yours, and what matters is that COBOL doesn't. Compare language or language, or component to component. (Not to mention that "embedded driver developer" is not s category I'd ever make - half of what an embedded developer does would be classified as "drivers", and that term is only really used for non-embedded.)
  - _DeadFred_ 2y ago
    Yes. I take numbers from IBM as true. I'm not a conspiracy theorist. As I'm not a conspiracy theorist online numbers definitely give close enough for an online discussion. We aren't talking about legalities of a law, we are talking general conversational understanding. Compare use case to use case, not language to language. You say if XYZ doesn't have developers, it shouldn't be used. Now you are saying 'but for your embedded, other people can be trained up'. Guess what, we can train up COBOL developers MORE easily than embedded driver devs. Your argument doesn't make any sense. By your argument we should not build systems around embedded drivers. I've know embedded driver developers and you are completely wrong. They print money. CISCO had to bring my acquaintance back multiple times because again it's such a niche field and no one could do what he did. Same with my buddy that did washing machines. Same with my buddy that did street lights. It is a small subset that do the drivers. Totally relevant to the discussion of 'Can we afford to be dependant on such a niche field'. And the answer is 100% yes, we can.
    - arghwhat 2y ago
      > 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.

IBM puts the number of COBOL devs at around 2 million, others around 1 million. Full-time experienced people is placed at around 200,000. Total embedded devs are around 2-2.5 million, but embedded driver devs are a much smaller subset. Hard to find numbers but probably around again 200,000 full time experienced so roughly the same amount.

arghwhat 2y ago
So numbers from the only supplier...? You are making a false comparison. Even if we assume the number is correct, you're making a false comparison - COBOL is a language, "embedded drivers" is a software component. The equivalent to your COBOL number is all C/C++ developers. Looking at some random online statistics like you did, COBOL is at 0.7% usage in 2024 vs. 20.3% for C and 23% for C++. Is that statistic credible? No, but neither is yours, and what matters is that COBOL doesn't. Compare language or language, or component to component. (Not to mention that "embedded driver developer" is not s category I'd ever make - half of what an embedded developer does would be classified as "drivers", and that term is only really used for non-embedded.)
- _DeadFred_ 2y ago
  Yes. I take numbers from IBM as true. I'm not a conspiracy theorist. As I'm not a conspiracy theorist online numbers definitely give close enough for an online discussion. We aren't talking about legalities of a law, we are talking general conversational understanding. Compare use case to use case, not language to language. You say if XYZ doesn't have developers, it shouldn't be used. Now you are saying 'but for your embedded, other people can be trained up'. Guess what, we can train up COBOL developers MORE easily than embedded driver devs. Your argument doesn't make any sense. By your argument we should not build systems around embedded drivers. I've know embedded driver developers and you are completely wrong. They print money. CISCO had to bring my acquaintance back multiple times because again it's such a niche field and no one could do what he did. Same with my buddy that did washing machines. Same with my buddy that did street lights. It is a small subset that do the drivers. Totally relevant to the discussion of 'Can we afford to be dependant on such a niche field'. And the answer is 100% yes, we can.
  - arghwhat 2y ago
    > 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.