5 ms·

You never said "C" but perhaps you think there is "a reason" why C still exists too. The only reason ineffective tools like C exist is because there are people

You never said "C" but perhaps you think there is "a reason" why C still exists too. The only reason ineffective tools like C exist is because there are people at the other extreme from those kids: Not take any risk but stick with tried and wrong tools.

protocode 8y ago
C still has it's place. It's not glamorous, but it works. COBOL has no decent replacements. Yet. Some have tried. Almost all have failed. Old does not mean useless. If it works, then it's not wrong.
- pjmlp 8y ago
  On UNIX clones and embedded developers that won't take anything else even at point gun. .NET, Java are good COBOL replacements. http://www.fujitsu.com/global/products/software/developer-tool/netcobol/ http://www.fujitsu.com/global/products/software/developer-to... https://www.microfocus.com/products/visual-cobol/ https://www.microfocus.com/products/visual-cobol/
  - coldtea 8y ago
    >.NET, Java are good COBOL replacements. Not even close. As for the links, those are still about COBOL the language.
    - pjmlp 8y ago
      I guess you need to inform yourself about migration projects that use those products to bring COBOL codebases to modern platforms, where new features are then written in Java/.NET languages, while the old working code is left as is.
      - coldtea 8y ago
        Nobody argued that new features could be "written in Java/.NET languages". Not even that COBOL codebases could be bridged and work "left as is" alongside those. The main objection was with the word "good".
        pjmlp 8y ago
        Except you have your definition of "good" and I have mine. This statement is meaningless without additional information. > COBOL has no decent replacements.
deleted 8y ago
[deleted]
coldtea 8y ago
Nope, there are tons of other reasons. Huge pool of programmers. Huge pool of libraries. Tons of existing code that should continue to run. Excellent documentation. Very fast compilers. Debuggers and profilers a plenty. Top notch vendor support. Choices of IDEs. Works great in embedded. Predictable. The alternatives being what, e.g. Rust, a 5 year old language with a single implementation that still tries to find its place, and brings extra baggage to the table? >Not take any risk but stick with tried and wrong tools. Engineers don't take risks. You wouldn't want risks in the people building your bridges and planes, why would you want in your OSes and network infrastructure?
- blub 8y ago
  Rust, D or Go could be alternatives, but they have limitations in certain domains and types of projects. C++ doesn't though, and that's why traditional C projects switch. At least in automotive it seems to be the language of choice.

protocode 8y ago

C still has it's place. It's not glamorous, but it works. COBOL has no decent replacements. Yet. Some have tried. Almost all have failed. Old does not mean useless. If it works, then it's not wrong.

pjmlp 8y ago
On UNIX clones and embedded developers that won't take anything else even at point gun. .NET, Java are good COBOL replacements. http://www.fujitsu.com/global/products/software/developer-tool/netcobol/ http://www.fujitsu.com/global/products/software/developer-to... https://www.microfocus.com/products/visual-cobol/ https://www.microfocus.com/products/visual-cobol/
- coldtea 8y ago
  >.NET, Java are good COBOL replacements. Not even close. As for the links, those are still about COBOL the language.
  - pjmlp 8y ago
    I guess you need to inform yourself about migration projects that use those products to bring COBOL codebases to modern platforms, where new features are then written in Java/.NET languages, while the old working code is left as is.
    - coldtea 8y ago
      Nobody argued that new features could be "written in Java/.NET languages". Not even that COBOL codebases could be bridged and work "left as is" alongside those. The main objection was with the word "good".
      - pjmlp 8y ago
        Except you have your definition of "good" and I have mine. This statement is meaningless without additional information. > COBOL has no decent replacements.

deleted 8y ago

[deleted]

coldtea 8y ago

Nope, there are tons of other reasons. Huge pool of programmers. Huge pool of libraries. Tons of existing code that should continue to run. Excellent documentation. Very fast compilers. Debuggers and profilers a plenty. Top notch vendor support. Choices of IDEs. Works great in embedded. Predictable. The alternatives being what, e.g. Rust, a 5 year old language with a single implementation that still tries to find its place, and brings extra baggage to the table? >Not take any risk but stick with tried and wrong tools. Engineers don't take risks. You wouldn't want risks in the people building your bridges and planes, why would you want in your OSes and network infrastructure?

blub 8y ago
Rust, D or Go could be alternatives, but they have limitations in certain domains and types of projects. C++ doesn't though, and that's why traditional C projects switch. At least in automotive it seems to be the language of choice.