5 ms·

Then C++ has failed. If it has so many competing standards and subsets, then it is too fragmented. This is why when you see C++ written in one standard it looks

Then C++ has failed. If it has so many competing standards and subsets, then it is too fragmented. This is why when you see C++ written in one standard it looks like a whole other language when you look at other C++. If after a decade there are so many details still obscured from you, then that's pretty much again a fault of the overly-engineered and tacked on language called C++. Other mainstream language work fine and allow you to still write clean and modern code without having literally dozens of subsets and implementations. So why is it that C++ feels the need to have so many?

pjmlp 9y ago
Then by that point of view, C (hello UB), Python, Ruby, JavaScript, Java, among many other programming languages have failed as well. Using my favorite scripting language (Python) as an example, I always need to check which version is installed on a given OS and then validate at https://docs.python.org/ https://docs.python.org/ if all the features I want are actually available on that version. Not to mention CPython, PyPy, Cython, JPython differences on top of that.
fsloth 9y ago
We use C++ because of the C++ the ecosystem not because of the C++ the language. There really is no other language that fits all of the constraints C++ fits. If there was, I'd be using it. And before you ask 'Have you looked into...' the answer is yes, unless the language is obscure, in which case it lacks the ecological robustness of C++.
- FiveDegrees 9y ago
  I hope Jai ends up being made interoperable with C++.
  - imron 9y ago
    I just hope Jai end up being released. jblow, I know you read HN, lots of us are looking forward to Jai.
    - cr0sh 9y ago
      Gotta say I'm looking forward to it too, even though I might not ever use it. There are some things I disagree on with it, but most of those are orthogonal to the domain of which the language was meant to be applied, namely game programming. For that end, I can get behind those. That said - the main things I don't like are the lack of exception handling, and no automatic memory management. I understand for game programming why these aren't going to be a part of the language. At the same time, I fear that without these, it may relegate the language to something of a niche language only used for game development and nothing else. While it is laudable to think that these features aren't needed, there is a reason they became available - and it mainly has to do with the fact that even "good programmers" aren't "perfect programmers"; we are all humans, not machines. Features that make the language stand out, though, are the ideas of functions that run at compile time, which allow for a build system that is written in Jai and builds on compile (so you don't need to learn some other "language" just for building your world), the whole AOS/SOA mess that is made simple to implement with only one keyword (kinda neat!), plus the whole "uplift" of code from inner to global usage, with minimal changes, as it morphs from "lines of code" to "capture" to "anonymous function", etc - that's pretty powerful. The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor. There's one part on this that I question - namely that variables are declared like: name: type = value ...so: foo: int = 0; ...but functions are defined as: name := () -> return_type {} ie: bar := () -> float {} I would have thought that a function would be defined as: name: return_type = () {} so: baz: float = () {} ...thus more like the variable declarations (plus it would allow for turning a variable into a function easier, perhaps). There is probably something about compiler design, parsing, etc that I don't know that pre-empted things? That would be my first guess as to why this difference exists, but I would love to hear the actual reason from the author, if he reads this.
      - ndh2 9y ago
        > no automatic memory management Pretty sure Jai is already powerful enough that you could add this dynamically to any program.
      - harrisi 9y ago
flohofwoe 9y ago
On the contrary, the one nice thing about C++ is that it is 'multi-paradigm'. Don't like boost's philosophy of overengineering every little detail? Then don't use boost. C++ without exceptions, RTTI, or even the whole STL? Perfectly fine. Other languages don't have this freedom. It's a double-edged sword of course. Less freedom also means wasting less time with pointless discussions about which combination of C++ features is 'right'.
- imron 9y ago
  > Then don't use boost. After using boost in several projects and regretting it each time (slow compile times, painful to configure), I finally learned my lesson and "don't use boost" is now one of my guiding principles when programming in C++.
  - ndh2 9y ago
    While I would mostly agree, I would humbly suggest a small nudge in perspective: Boost does not equal Boost. While I passionately hate most of Boost, I find boost::optional to be one of the most useful template classes. So you shouldn't treat Boost as one library, but as a collection of different libraries. Same goes for STL in my opinion.
    - imron 9y ago
      I think boost has definitely had a positive impact on c++ and the fact that large amounts of it are now in (or had a major influence on) the std library certainly makes it much easier to forgoe using it.
- nurettin 9y ago
  I use boost filesystem and string algos. I can't say they slow down compilation that much. And they save a lot of typing.
  - VHRanger 9y ago
    Theres filesystem TS in c++17. Also experimental/filesystem in all compilers except gcc since 2014
ksk 9y ago
Which other systems language allows the same style of programming while giving the same performance? You pretty much know if and when you need C++ - which is rare unless you live near the hardware. That said, I'm not sure how you wish to engage people here with that comment. Do you have any specific criticisms of C++ (there are many!) that we can discuss beyond your personal feelings?
- deleted 9y ago
  [deleted]
- sqeaky 9y ago
  I would disagree that C++ is only useful "near the hardware" I have spent the bulk of my career not near the hardware and have found C++ to be the most useful of languages I have learned. My current job is as close to the hardware as I have gotten, I am even on the "Firmware Team" and I feel pretty removed. If you need interop between two languages you almost always have to drop to C, if you want to do that while keeping high level concepts like object, then use C++. If you need more performance and you have already maxed out perf in some "higher" language. Then a naive C++ rewrite is often just faster. Then when you start breaking out C++ profiling tools and carefully managing memory you get insane speeds that didn't seem possible before. With some of new stuff in C++11/14/17 it is actually fun to work in C++, not as fun as Ruby... up until 3d things start appearing on the screen.
  - ksk 9y ago
    >I would disagree that C++ is only useful "near the hardware" Okay, but I didn't say that? I said C++ has limited uses, _unless_ you're near the hardware, where its much more common. You can disagree, but its better if you disagree with what I actually said :P But to your reply, Personally, I don't agree that C++ is fun to work with. Like any other language, I tolerate it as and when I need to. And like I said in the previous reply, sometimes C++ is the only choice, and you accept that and do the best you can. I've found that good tooling does reduce some of the headaches, especially when it comes to debugging (although stepping through optimized production code still remains a giant pain in the ass). I'm happy that the language is progressing and with all of the new features, its like a cafeteria where you chose what you like and what works for you and your team. I certainly don't agree with all the advice that the C++ cheerleaders put out on the internet about inserting every new feature into production code. Personally I take a very conservative approach and only use features that have shown tobe useful across the entire dev cycle of - helping to conceptualize an idea, being easy to reason about by everyone on the team, being easy to debug, and being reliable enough for 24/7 execution (though this applies more to the library side of things). My code runs automation machinery, and it has to have zero bugs in it. I choose C++ because currently its the best tool for the job.

pjmlp 9y ago

Then by that point of view, C (hello UB), Python, Ruby, JavaScript, Java, among many other programming languages have failed as well. Using my favorite scripting language (Python) as an example, I always need to check which version is installed on a given OS and then validate at https://docs.python.org/ https://docs.python.org/ if all the features I want are actually available on that version. Not to mention CPython, PyPy, Cython, JPython differences on top of that.

fsloth 9y ago

We use C++ because of the C++ the ecosystem not because of the C++ the language. There really is no other language that fits all of the constraints C++ fits. If there was, I'd be using it. And before you ask 'Have you looked into...' the answer is yes, unless the language is obscure, in which case it lacks the ecological robustness of C++.

FiveDegrees 9y ago
I hope Jai ends up being made interoperable with C++.
- imron 9y ago
  I just hope Jai end up being released. jblow, I know you read HN, lots of us are looking forward to Jai.
  - cr0sh 9y ago
    Gotta say I'm looking forward to it too, even though I might not ever use it. There are some things I disagree on with it, but most of those are orthogonal to the domain of which the language was meant to be applied, namely game programming. For that end, I can get behind those. That said - the main things I don't like are the lack of exception handling, and no automatic memory management. I understand for game programming why these aren't going to be a part of the language. At the same time, I fear that without these, it may relegate the language to something of a niche language only used for game development and nothing else. While it is laudable to think that these features aren't needed, there is a reason they became available - and it mainly has to do with the fact that even "good programmers" aren't "perfect programmers"; we are all humans, not machines. Features that make the language stand out, though, are the ideas of functions that run at compile time, which allow for a build system that is written in Jai and builds on compile (so you don't need to learn some other "language" just for building your world), the whole AOS/SOA mess that is made simple to implement with only one keyword (kinda neat!), plus the whole "uplift" of code from inner to global usage, with minimal changes, as it morphs from "lines of code" to "capture" to "anonymous function", etc - that's pretty powerful. The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor. There's one part on this that I question - namely that variables are declared like: name: type = value ...so: foo: int = 0; ...but functions are defined as: name := () -> return_type {} ie: bar := () -> float {} I would have thought that a function would be defined as: name: return_type = () {} so: baz: float = () {} ...thus more like the variable declarations (plus it would allow for turning a variable into a function easier, perhaps). There is probably something about compiler design, parsing, etc that I don't know that pre-empted things? That would be my first guess as to why this difference exists, but I would love to hear the actual reason from the author, if he reads this.
    - ndh2 9y ago
      > no automatic memory management Pretty sure Jai is already powerful enough that you could add this dynamically to any program.
    - harrisi 9y ago

flohofwoe 9y ago

On the contrary, the one nice thing about C++ is that it is 'multi-paradigm'. Don't like boost's philosophy of overengineering every little detail? Then don't use boost. C++ without exceptions, RTTI, or even the whole STL? Perfectly fine. Other languages don't have this freedom. It's a double-edged sword of course. Less freedom also means wasting less time with pointless discussions about which combination of C++ features is 'right'.

imron 9y ago
> Then don't use boost. After using boost in several projects and regretting it each time (slow compile times, painful to configure), I finally learned my lesson and "don't use boost" is now one of my guiding principles when programming in C++.
- ndh2 9y ago
  While I would mostly agree, I would humbly suggest a small nudge in perspective: Boost does not equal Boost. While I passionately hate most of Boost, I find boost::optional to be one of the most useful template classes. So you shouldn't treat Boost as one library, but as a collection of different libraries. Same goes for STL in my opinion.
  - imron 9y ago
    I think boost has definitely had a positive impact on c++ and the fact that large amounts of it are now in (or had a major influence on) the std library certainly makes it much easier to forgoe using it.
nurettin 9y ago
I use boost filesystem and string algos. I can't say they slow down compilation that much. And they save a lot of typing.
- VHRanger 9y ago
  Theres filesystem TS in c++17. Also experimental/filesystem in all compilers except gcc since 2014

ksk 9y ago

Which other systems language allows the same style of programming while giving the same performance? You pretty much know if and when you need C++ - which is rare unless you live near the hardware. That said, I'm not sure how you wish to engage people here with that comment. Do you have any specific criticisms of C++ (there are many!) that we can discuss beyond your personal feelings?

deleted 9y ago
[deleted]
sqeaky 9y ago
I would disagree that C++ is only useful "near the hardware" I have spent the bulk of my career not near the hardware and have found C++ to be the most useful of languages I have learned. My current job is as close to the hardware as I have gotten, I am even on the "Firmware Team" and I feel pretty removed. If you need interop between two languages you almost always have to drop to C, if you want to do that while keeping high level concepts like object, then use C++. If you need more performance and you have already maxed out perf in some "higher" language. Then a naive C++ rewrite is often just faster. Then when you start breaking out C++ profiling tools and carefully managing memory you get insane speeds that didn't seem possible before. With some of new stuff in C++11/14/17 it is actually fun to work in C++, not as fun as Ruby... up until 3d things start appearing on the screen.
- ksk 9y ago
  >I would disagree that C++ is only useful "near the hardware" Okay, but I didn't say that? I said C++ has limited uses, _unless_ you're near the hardware, where its much more common. You can disagree, but its better if you disagree with what I actually said :P But to your reply, Personally, I don't agree that C++ is fun to work with. Like any other language, I tolerate it as and when I need to. And like I said in the previous reply, sometimes C++ is the only choice, and you accept that and do the best you can. I've found that good tooling does reduce some of the headaches, especially when it comes to debugging (although stepping through optimized production code still remains a giant pain in the ass). I'm happy that the language is progressing and with all of the new features, its like a cafeteria where you chose what you like and what works for you and your team. I certainly don't agree with all the advice that the C++ cheerleaders put out on the internet about inserting every new feature into production code. Personally I take a very conservative approach and only use features that have shown tobe useful across the entire dev cycle of - helping to conceptualize an idea, being easy to reason about by everyone on the team, being easy to debug, and being reliable enough for 24/7 execution (though this applies more to the library side of things). My code runs automation machinery, and it has to have zero bugs in it. I choose C++ because currently its the best tool for the job.