4 ms·

I think this can apply for some things and not others. I mean, imagine replacing GCC. Obviously, it'd be better to do. I've heard it's one of the worst code bas

by earlz 12y ago

I think this can apply for some things and not others. I mean, imagine replacing GCC. Obviously, it'd be better to do. I've heard it's one of the worst code bases to contribute to. Or look at OpenSSL even. For some things you need compatibility, and that means that writing a replacement must be done extremely carefully and will require significant effort.

johan_larson 12y ago
GCC will probably never be replaced. The current C++ standard is so monstrously complicated that implementing a full compiler would be an enormous task. But it doesn't matter, because eventually few or no new projects will be done in C++. Consider the fate of COBOL, which was once a shiny new language, a real step up from coding business application in assembler. It's now a tired old has-been, used only for patching up legacy systems. As a system ages, it becomes more and more complicated because it is serving more and more purposes. Accordingly making upgrades while preserving backward compatibility becomes harder and harder. I remember hearing about an old AT&T switch with software so intricate that in the end it required one meeting for every line of code changed. And so progress grinds to a halt. At some point, you either break backward compatibility or face stagnation. Careful modularization and upgrades can push back the boundary, but not forever. Even good practices, good people, and a good organization can only tame so much complexity.
- tbrownaw 12y ago
  So LLVM is what, chopped liver? . COBOL had a purpose, which was making programs more readable / understandable. We now have much better ways to do that, and it's a primary area of research. C++ has a purpose, which is to maximize abstraction without imposing any unnecessary runtime cost. But we're not focused on doing better at this, since most applications don't really care about performance. C++ may become somewhat of a niche language only used to build the invisible low-level stuff, but it will never go the way of COBOL until something better at its purpose comes along (I've heard good things about Rust?).
  - angersock 12y ago
    You know, as much as I've heard some variation on that phrase, I've yet to see the benefits in practice--at least not from the last couple of revisions of the language.
    - rbsn 12y ago
      Are you speaking of COBOL or C++?
      - angersock 12y ago
        C++.
- groby_b 12y ago
  LLVM would be an enormous task to write, indeed. Thankfully, it's done already :) Your tired has-been COBOL is so infrequently used that on Tiobe, it outranks D, Erlang, Common Lisp, Haskell, Scala, Go, Lua, ... In light of that, I'd be careful with predictions like "few or no new projects will be done in C++". It might be a long while before we reach that point.
  - dllthomas 12y ago
    "Your tired has-been COBOL is so infrequently used that on Tiobe, it outranks D, Erlang, Common Lisp, Haskell, Scala, Go, Lua, ..." Is that for new projects, though?
    - pjmlp 12y ago
      There are guys earning enough for early retirement thanks to specializing in mainframes, COBOL and similar systems. You won't get stuff to post on HN, but the bank accountant will be very happy.
      - AnimalMuppet 12y ago
        You didn't answer his question, though. His question was whether COBOL was being used for new development. Is anyone, when writing a new program from scratch, doing so in COBOL? I hope not.
        pjmlp 12y ago
        I guess you aren't aware of COBOL for Java and .NET. http://www.gtsoftware.com/netcobol-2/ http://www.gtsoftware.com/netcobol-2/ http://www.fujitsu.com/global/products/software/developer-tool/netcobol/ http://www.fujitsu.com/global/products/software/developer-to... http://www.microfocus.com/products/micro-focus-developer/visual_cobol/ http://www.microfocus.com/products/micro-focus-developer/vis... Or that since COBOL 2002 there is support for OOP, and the standard just got a new revision this year. Most corporations of enterprise level, seldom write full new applications, rather extensions to existing systems. So the language depends a lot of the pool of available skills. If the employees are COBOL guys, the new modules will be COBOL as well.
hgh 12y ago
I tried to hack on g++ as part of project years ago, but really struggled to make any contribution. The codebase is indeed monstrously complex, but the core development team is also very protective. A secondary effect of the growing complexity in an open source project is the decreasing willingness for the core team to bring in new people because of the time/effort cost involved and potential risks. If the team naturally atrophies over time, you end up with increasing stagnation.

by earlz 12y ago

johan_larson 12y ago

GCC will probably never be replaced. The current C++ standard is so monstrously complicated that implementing a full compiler would be an enormous task. But it doesn't matter, because eventually few or no new projects will be done in C++. Consider the fate of COBOL, which was once a shiny new language, a real step up from coding business application in assembler. It's now a tired old has-been, used only for patching up legacy systems. As a system ages, it becomes more and more complicated because it is serving more and more purposes. Accordingly making upgrades while preserving backward compatibility becomes harder and harder. I remember hearing about an old AT&T switch with software so intricate that in the end it required one meeting for every line of code changed. And so progress grinds to a halt. At some point, you either break backward compatibility or face stagnation. Careful modularization and upgrades can push back the boundary, but not forever. Even good practices, good people, and a good organization can only tame so much complexity.

tbrownaw 12y ago
So LLVM is what, chopped liver? . COBOL had a purpose, which was making programs more readable / understandable. We now have much better ways to do that, and it's a primary area of research. C++ has a purpose, which is to maximize abstraction without imposing any unnecessary runtime cost. But we're not focused on doing better at this, since most applications don't really care about performance. C++ may become somewhat of a niche language only used to build the invisible low-level stuff, but it will never go the way of COBOL until something better at its purpose comes along (I've heard good things about Rust?).
- angersock 12y ago
  You know, as much as I've heard some variation on that phrase, I've yet to see the benefits in practice--at least not from the last couple of revisions of the language.
  - rbsn 12y ago
    Are you speaking of COBOL or C++?
    - angersock 12y ago
      C++.
groby_b 12y ago
LLVM would be an enormous task to write, indeed. Thankfully, it's done already :) Your tired has-been COBOL is so infrequently used that on Tiobe, it outranks D, Erlang, Common Lisp, Haskell, Scala, Go, Lua, ... In light of that, I'd be careful with predictions like "few or no new projects will be done in C++". It might be a long while before we reach that point.
- dllthomas 12y ago
  "Your tired has-been COBOL is so infrequently used that on Tiobe, it outranks D, Erlang, Common Lisp, Haskell, Scala, Go, Lua, ..." Is that for new projects, though?
  - pjmlp 12y ago
    There are guys earning enough for early retirement thanks to specializing in mainframes, COBOL and similar systems. You won't get stuff to post on HN, but the bank accountant will be very happy.
    - AnimalMuppet 12y ago
      You didn't answer his question, though. His question was whether COBOL was being used for new development. Is anyone, when writing a new program from scratch, doing so in COBOL? I hope not.
      - pjmlp 12y ago
        I guess you aren't aware of COBOL for Java and .NET. http://www.gtsoftware.com/netcobol-2/ http://www.gtsoftware.com/netcobol-2/ http://www.fujitsu.com/global/products/software/developer-tool/netcobol/ http://www.fujitsu.com/global/products/software/developer-to... http://www.microfocus.com/products/micro-focus-developer/visual_cobol/ http://www.microfocus.com/products/micro-focus-developer/vis... Or that since COBOL 2002 there is support for OOP, and the standard just got a new revision this year. Most corporations of enterprise level, seldom write full new applications, rather extensions to existing systems. So the language depends a lot of the pool of available skills. If the employees are COBOL guys, the new modules will be COBOL as well.

hgh 12y ago

I tried to hack on g++ as part of project years ago, but really struggled to make any contribution. The codebase is indeed monstrously complex, but the core development team is also very protective. A secondary effect of the growing complexity in an open source project is the decreasing willingness for the core team to bring in new people because of the time/effort cost involved and potential risks. If the team naturally atrophies over time, you end up with increasing stagnation.