6 ms·

I'm not. Just like I'm ok with VHS and scan lines becoming niche markets, we need to push forward in programming language design. We've come a long way in the p

I'm not. Just like I'm ok with VHS and scan lines becoming niche markets, we need to push forward in programming language design. We've come a long way in the past 35 years; lessons have been learned, the field of programming language theory has progressed, and we're ready to iterate. C++ has been retrofitted, but like Java, it's commitment to backwards compatibility has ballooned complexity to an unsustainable point, and there are simply too many things that will never be fixed, and C compatibility will never be dropped. We need to forge forward, and support the next generation of programming languages.

risaacs99 8y ago
Well that's just like, your opinion, man. In all seriousness, C and C++ are with us forever. Improving and moving these languages forward, and improving their safety with static and runtime analysis (and hardware support) has to be part of the plan moving forward.
- ilovecaching 8y ago
  To me, that's a very bleak outlook, and as I already mentioned, retrofitting C++ will never solve all of these issues; retrofits are always additive, and simply increase the complexity of the compiler and specification to the point that very few people actually understand the majority of C++'s semantics. Retrofitting also doesn't solve the philosophy of a language. There are simply aspects of C++ that are too vital to its identity to change. Is object oriented programming the final word on abstraction in programming? Probably not. This is a young field, and there are always better solutions lurking around the corner. When we buy into the notion that something should live forever, we rob ourselves of the opportunity to move forward, or to at least know with certainty whether something is truly the best. Unless we want to repeat what has happened with COBOL, where the systems have lasted forever to the point that all of the COBOL programmers are dead or retired, we need to start evolving our philosophy to favor language replace-ability, or stop guaranteeing backwards compatibility. The latter is untenable to most businesses, while the former can be achieved through the use of small services, FFIs, RPC, and system modularity.
  - 7e 8y ago
    C++ does remove deprecated features, but so far there has been no reason to deprecate OOP. The fundamentalist viewpoint you're espousing is not particularly convincing; in particular, the amount of labor required to kill and replace working systems for aesthetic reasons (as opposed to evolving them) would remove much of the free time required to create new and innovative technology.
    - ilovecaching 8y ago
      Which is why I also said that we need to evolve our thinking towards replaceable systems. As systems grow, the pace of innovation slows as it becomes cumbersome to make changes, and the barrier to entry into the code base rises. With that in mind, we are well served to replace programming languages as a means of maintaining constant velocity in our development. I don't claim that existing systems are easy to replace, but I do posit that they can be made replaceable given that certain practices are adopted, and the mindset of the developers is that they system should be easy to remove and replace.
      - shaklee3 8y ago
        What languages in particular are you suggesting we move towards? Rust is getting there, but it's still evolving rapidly with features. That's about it. Any HN-favorite, such as Go, is not a valid replacement.
        ilovecaching 8y ago
        I'm personally behind Rust and Go, but I don't want that conflated with the point I'm trying to make about facilitating code replace-ability. We shouldn't move towards any language in particular, but instead facilitate interoperability of languages, focus on building services instead of libraries, and size services such that they can be easily replaced. A business doesn't need to use a different language per developer, but they should expect to phase out languages periodically, and accept more rewrites and make more consideration about the right tool for the job when greenfielding that jumping to some mandated language like Java. I also wouldn't say that Go is invalid, Go is more than production ready; it's actually in production in critical infrastructure today at scale.
echelon 8y ago
That's what Rust does so well. Existing C++ can be wrapped or ported. New stuff should be implemented in Rust from the outset.
- htfy96 8y ago
  The opposite is also correct. Last week I wrapped a Rust application into C++ application.
- ilovecaching 8y ago
  I have found Rust's C++ story better than most. C++ is unfortunately a hard language to interoperate with. Rust's C story is absolutely unparalleled, and an easy to way to share code between the two languages.
  - ridiculous_fish 8y ago
    Strange comment, since C++'s "C story" is better than Rust's C story. (ObjC too.) As for C++ interop, ObjC++ is the best I've seen; is there something better?
    - ilovecaching 8y ago
      I disagree. Rust has managed to have great interoperability, but hasn't made the sacrifice of backwards compatibility that has plagued C++. C++ is also ever so slightly different, and surprising things can happen trying to compile C using a C++ compiler. Rust makes the interface explicit, which is easier to reason about.
      - ridiculous_fish 8y ago
        I'm not super-familiar with Rust's C interop - it it really that good? Does it support preprocessor macros? Can it inline C functions from header files? Does it know about function attributes like pure? If you believe that C++ "sacrificed" for backwards compatibility (and I agree), well what was that sacrifice for anyways, if not better compatibility?

risaacs99 8y ago

Well that's just like, your opinion, man. In all seriousness, C and C++ are with us forever. Improving and moving these languages forward, and improving their safety with static and runtime analysis (and hardware support) has to be part of the plan moving forward.

ilovecaching 8y ago
To me, that's a very bleak outlook, and as I already mentioned, retrofitting C++ will never solve all of these issues; retrofits are always additive, and simply increase the complexity of the compiler and specification to the point that very few people actually understand the majority of C++'s semantics. Retrofitting also doesn't solve the philosophy of a language. There are simply aspects of C++ that are too vital to its identity to change. Is object oriented programming the final word on abstraction in programming? Probably not. This is a young field, and there are always better solutions lurking around the corner. When we buy into the notion that something should live forever, we rob ourselves of the opportunity to move forward, or to at least know with certainty whether something is truly the best. Unless we want to repeat what has happened with COBOL, where the systems have lasted forever to the point that all of the COBOL programmers are dead or retired, we need to start evolving our philosophy to favor language replace-ability, or stop guaranteeing backwards compatibility. The latter is untenable to most businesses, while the former can be achieved through the use of small services, FFIs, RPC, and system modularity.
- 7e 8y ago
  C++ does remove deprecated features, but so far there has been no reason to deprecate OOP. The fundamentalist viewpoint you're espousing is not particularly convincing; in particular, the amount of labor required to kill and replace working systems for aesthetic reasons (as opposed to evolving them) would remove much of the free time required to create new and innovative technology.
  - ilovecaching 8y ago
    Which is why I also said that we need to evolve our thinking towards replaceable systems. As systems grow, the pace of innovation slows as it becomes cumbersome to make changes, and the barrier to entry into the code base rises. With that in mind, we are well served to replace programming languages as a means of maintaining constant velocity in our development. I don't claim that existing systems are easy to replace, but I do posit that they can be made replaceable given that certain practices are adopted, and the mindset of the developers is that they system should be easy to remove and replace.
    - shaklee3 8y ago
      What languages in particular are you suggesting we move towards? Rust is getting there, but it's still evolving rapidly with features. That's about it. Any HN-favorite, such as Go, is not a valid replacement.
      - ilovecaching 8y ago
        I'm personally behind Rust and Go, but I don't want that conflated with the point I'm trying to make about facilitating code replace-ability. We shouldn't move towards any language in particular, but instead facilitate interoperability of languages, focus on building services instead of libraries, and size services such that they can be easily replaced. A business doesn't need to use a different language per developer, but they should expect to phase out languages periodically, and accept more rewrites and make more consideration about the right tool for the job when greenfielding that jumping to some mandated language like Java. I also wouldn't say that Go is invalid, Go is more than production ready; it's actually in production in critical infrastructure today at scale.

echelon 8y ago

That's what Rust does so well. Existing C++ can be wrapped or ported. New stuff should be implemented in Rust from the outset.

htfy96 8y ago
The opposite is also correct. Last week I wrapped a Rust application into C++ application.
ilovecaching 8y ago
I have found Rust's C++ story better than most. C++ is unfortunately a hard language to interoperate with. Rust's C story is absolutely unparalleled, and an easy to way to share code between the two languages.
- ridiculous_fish 8y ago
  Strange comment, since C++'s "C story" is better than Rust's C story. (ObjC too.) As for C++ interop, ObjC++ is the best I've seen; is there something better?
  - ilovecaching 8y ago
    I disagree. Rust has managed to have great interoperability, but hasn't made the sacrifice of backwards compatibility that has plagued C++. C++ is also ever so slightly different, and surprising things can happen trying to compile C using a C++ compiler. Rust makes the interface explicit, which is easier to reason about.
    - ridiculous_fish 8y ago
      I'm not super-familiar with Rust's C interop - it it really that good? Does it support preprocessor macros? Can it inline C functions from header files? Does it know about function attributes like pure? If you believe that C++ "sacrificed" for backwards compatibility (and I agree), well what was that sacrifice for anyways, if not better compatibility?