Hacker News Reader

Comment by earlz | Hacker News Reader

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.

View on HN

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.

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?).

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.

Are you speaking of COBOL or C++?

C++.

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.

"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?

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.

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.

I guess you aren't aware of COBOL for Java and .NET.

http://www.gtsoftware.com/netcobol-2/

http://www.fujitsu.com/global/products/software/developer-to...

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.

I guess a lot depends on how you draw the line of "new project".

For what I'm aware of, that's all maintenance and extension of existing projects. Is COBOL being used for new projects anywhere? That was my question, and the only thing relevant to the original claim.

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.

Reply on news.ycombinator.com